Skip to main content

Introdução ao TDD para Novos Desenvolvedores

Manual de Desenvolvimento Guiado por Testes (TDD) para Novos Desenvolvedores

Introdução: Por que começar pelos testes?​

Olá, novo(a) desenvolvedor(a)! Bem-vindo(a) à nossa equipe. Uma das práticas fundamentais que valorizamos e que fará uma grande diferença na qualidade do seu código e na sua produtividade é o Desenvolvimento Guiado por Testes, ou TDD (do inglês, Test-Driven Development).

Sabemos que, no início, a ideia de escrever testes antes de escrever o código da funcionalidade pode parecer contraintuitiva ou até mesmo um passo extra que atrasa a entrega. Muitos se perguntam: "Como posso testar algo que ainda não existe?". Este manual tem como objetivo desmistificar o TDD, mostrar sua importância e, o mais importante, fornecer um guia prático – uma "receita de bolo" – para você começar a desenvolver suas features pensando em testabilidade desde o primeiro momento, especialmente utilizando Golang e o VS Code.

O foco aqui será em como o TDD pode transformar a maneira como você pensa sobre o design do seu código, tornando-o mais robusto, manutenível e, surpreendentemente, mais rápido de desenvolver a longo prazo. Vamos abordar como convencer você de que iniciar pelos testes não é um fardo, mas uma ferramenta poderosa para construir software de alta qualidade, com ênfase em como lidar com dependências comuns como bancos de dados e filas através de mocks, e a diferença crucial entre testes unitários e de integração.

O que é TDD (Desenvolvimento Guiado por Testes)?​

O Desenvolvimento Guiado por Testes (TDD) é uma abordagem de desenvolvimento de software onde os desenvolvedores escrevem testes automatizados antes de escrever o código de produção que implementa a funcionalidade desejada. Parece estranho à primeira vista, mas essa inversão de processo traz inúmeros benefícios.

A essência do TDD reside em um ciclo curto e repetitivo, conhecido como o ciclo Red-Green-Refactor:

  1. Red (Vermelho): Escreva um teste automatizado para uma pequena funcionalidade ou parte dela. Como o código da funcionalidade ainda não existe, este teste irá falhar (ficará "vermelho"). Este passo é crucial, pois ele define claramente o que você espera que seu código faça. Se o teste não falhar inicialmente, ele pode não estar testando o que você pensa, ou a funcionalidade já existe de alguma forma.

  2. Green (Verde): Escreva a quantidade mínima de código de produção necessária para fazer o teste passar (ficar "verde"). Neste momento, o objetivo não é escrever o código mais elegante ou otimizado, mas sim o código mais simples que satisfaça o teste. O foco é fazer o teste passar rapidamente.

  3. Refactor (Refatorar): Com o teste passando e garantindo que a funcionalidade está correta, agora você pode refatorar o código de produção com segurança. Refatorar significa melhorar a estrutura interna do código (torná-lo mais limpo, legível, eficiente, remover duplicação) sem alterar seu comportamento externo. Como você tem um teste que garante o comportamento, você pode fazer essas melhorias com a confiança de que não quebrará a funcionalidade.

Após a refatoração, o ciclo se repete para a próxima pequena funcionalidade ou melhoria. O TDD, portanto, não é apenas sobre testar; é uma disciplina de design que guia o desenvolvimento do software de forma incremental e segura.

Pensando a Aplicação de Modo Testável desde o Início:

Adotar o TDD força você a pensar sobre como sua funcionalidade será usada e como ela se comportará antes mesmo de você escrever uma linha de código de implementação. Isso leva a um design de software mais claro e modular. Ao escrever o teste primeiro, você está, na verdade, especificando a interface e o comportamento esperado do seu código. Se é difícil escrever um teste para uma determinada peça de código, isso geralmente é um sinal de que o design dessa peça de código pode ser complexo demais ou mal acoplado, incentivando você a simplificá-lo.

Nos próximos capítulos, exploraremos por que essa abordagem é tão importante e como aplicá-la na prática com Golang.

Por que TDD é Importante?​

Agora que entendemos o que é TDD e seu ciclo básico, você pode estar se perguntando: "Ok, mas por que devo me dar ao trabalho? Quais são os reais benefícios?"

A importância do TDD vai muito além de simplesmente "ter testes". Ele impacta positivamente diversas áreas do desenvolvimento de software:

  1. Melhora o Design do Código:

    • Acoplamento Baixo e Coesão Alta: Ao escrever testes primeiro, você é forçado a pensar em como seu código será utilizado. Isso naturalmente leva a componentes menores, mais focados (alta coesão) e com dependências bem definidas e gerenciáveis (baixo acoplamento). Se é difícil testar uma unidade de código, geralmente é um sinal de que ela está fazendo coisas demais ou está muito entrelaçada com outras partes do sistema.
    • Interfaces Claras: O teste atua como o primeiro cliente do seu código. Para testá-lo, você precisa de uma interface clara e bem definida. Isso resulta em APIs internas mais limpas e fáceis de usar.

  2. Reduz Bugs e Aumenta a Confiança:

    • Segurança para Refatorar: Como mencionado, o conjunto de testes automatizados atua como uma rede de segurança. Você pode refatorar e melhorar seu código com a confiança de que, se algo quebrar, os testes irão alertá-lo imediatamente. Isso encoraja melhorias contínuas no código sem o medo de introduzir regressões.
    • Detecção Antecipada de Erros: Bugs são encontrados muito mais cedo no ciclo de desenvolvimento (geralmente minutos após a escrita do código), quando são mais fáceis e baratos de corrigir.
    • Documentação Viva: Os testes servem como uma forma de documentação executável. Eles descrevem como cada parte do sistema deve se comportar e como ela deve ser usada. Ao contrário da documentação tradicional, que pode ficar desatualizada, os testes estão sempre sincronizados com o código (ou eles falham).

  3. Desenvolvimento Mais Rápido (a Longo Prazo):

    • Pode parecer que escrever testes primeiro torna o desenvolvimento mais lento, mas essa percepção geralmente é de curto prazo. A longo prazo, o tempo economizado na depuração, na correção de bugs em produção e na facilidade de manutenção e extensão do código compensa largamente o investimento inicial na escrita dos testes.
    • Feedback Rápido: O ciclo curto do TDD fornece feedback constante sobre o progresso e a corretude do seu trabalho.

  4. Simplifica a Depuração:

    • Quando um teste falha após uma alteração no código, você sabe exatamente qual funcionalidade foi afetada e, geralmente, a causa raiz do problema está no código que você acabou de escrever ou modificar. Isso torna a depuração muito mais direcionada e rápida.

  5. Foco no Requisito:

    • Cada teste é escrito para satisfazer uma pequena parte de um requisito. Isso ajuda a manter o foco no que realmente precisa ser implementado, evitando a superengenharia ou a adição de funcionalidades desnecessárias.

  6. Facilita a Colaboração e o Onboarding:

    • Um código bem testado é mais fácil para outros desenvolvedores (incluindo você no futuro ou novos membros da equipe) entenderem e modificarem com segurança.

Convencendo Você a Iniciar pelos Testes:

A maior barreira para iniciantes é, muitas vezes, a mudança de mentalidade. Em vez de ver os testes como uma tarefa separada e posterior, o TDD os integra ao processo de design e escrita do código. Pense nos testes como especificações executáveis do comportamento que você deseja. Ao escrever o teste primeiro, você está definindo o "contrato" que seu código deve cumprir.

Nos próximos capítulos, vamos mergulhar em como colocar isso em prática com Golang, mostrando como essa "receita de bolo" pode ser aplicada para construir funcionalidades de forma incremental e segura, e como isso ajuda a pensar em um design testável desde o início.

Como Desenvolver Baseado em Testes com Golang e VS Code (A "Receita de Bolo")​

Chegou a hora de colocar a mão na massa! Esta seção é o coração do nosso manual e vai guiar você, passo a passo, em como aplicar o TDD no seu dia a dia com Golang e o Visual Studio Code (VS Code), nosso editor padrão.

Lembre-se do ciclo: RED (escrever um teste que falha) -> GREEN (escrever o código mínimo para o teste passar) -> REFACTOR (melhorar o código).

Preparando o Ambiente (Go e VS Code)​

Antes de começarmos, garanta que você tem:

  1. Go Instalado: Se ainda não tem, siga as instruções no site oficial do Go. Após a instalação, configure seu GOPATH e GOROOT corretamente (as versões mais recentes do Go simplificam bastante isso com Go Modules, que usaremos).
  2. VS Code Instalado: Baixe e instale o VS Code.
  3. Extensão Go para VS Code: Dentro do VS Code, vá até a aba de Extensões (Ctrl+Shift+X ou Cmd+Shift+X) e procure por "Go" (geralmente a publicada pela equipe do Go na Microsoft). Instale-a. Esta extensão oferece excelente suporte para desenvolvimento Go, incluindo integração com ferramentas de teste, depuração, autocompletar, etc.
    • Após instalar a extensão, o VS Code pode pedir para instalar ferramentas adicionais do Go (como gopls para o language server, dlv para depuração, go-outline, etc.). Permita a instalação dessas ferramentas clicando em "Install All" quando solicitado.

Nosso Primeiro Exemplo: Uma Função de Soma Simples​

Vamos criar uma funcionalidade muito básica: uma função que soma dois números inteiros. Parece trivial, mas é perfeito para ilustrar o ciclo TDD.

Passo 0: Estrutura do Projeto

Crie uma nova pasta para o seu projeto, por exemplo, meuprojeto_tdd. Abra esta pasta no VS Code (File > Open Folder...).

Dentro desta pasta, crie um arquivo chamado soma.go e um arquivo de teste chamado soma_test.go. Em Go, os arquivos de teste devem terminar com _test.go e ficar no mesmo pacote (mesma pasta, geralmente) que o código que estão testando.

Inicialize o Go Modules no terminal integrado do VS Code (View > Terminal):

go mod init meuprojeto_tdd

Isso criará um arquivo go.mod.

Passo 1: RED - Escreva um Teste que Falha

Abra o arquivo soma_test.go e adicione o seguinte código:

package main // Ou o nome do seu pacote

import "testing"

func TestSoma(t *testing.T) {
    resultado := Soma(2, 2)
    esperado := 4

    if resultado != esperado {
        t.Errorf("Soma(2, 2) = %d; esperado %d", resultado, esperado)
    }
}

Entendendo o Teste:

  • package main: Declara que este arquivo pertence ao pacote main. Se você estiver criando uma biblioteca, usaria um nome de pacote diferente (e o soma.go também estaria nesse pacote).
  • import "testing": Importa o pacote testing nativo do Go, que fornece as ferramentas para escrever testes automatizados.
  • func TestSoma(t *testing.T): Esta é a função de teste. Em Go, funções de teste devem começar com a palavra Test seguida por um nome que descreva o que está sendo testado (aqui, Soma). Elas devem receber um único argumento do tipo *testing.T.
  • resultado := Soma(2, 2): Chamamos nossa função Soma (que ainda não existe!) com os valores 2 e 2.
  • esperado := 4: Definimos o resultado que esperamos.
  • if resultado != esperado: Comparamos o resultado obtido com o esperado.
  • t.Errorf("Soma(2, 2) = %d; esperado %d", resultado, esperado): Se o resultado for diferente do esperado, t.Errorf é chamado. Isso marca o teste como falho e registra a mensagem de erro formatada.

Rodando o Teste (e Vendo Falhar):

No terminal do VS Code, dentro da pasta do projeto, execute:

go test

Você verá um erro de compilação, algo como:

# meuprojeto_tdd
./soma_test.go:6:14: undefined: Soma
FAIL    meuprojeto_tdd [build failed]

Perfeito! O teste está "vermelho" porque a função Soma nem sequer existe. Este é o primeiro tipo de falha que esperamos: o código não compila.

Passo 2: GREEN - Escreva o Código Mínimo para o Teste Passar

Agora, abra o arquivo soma.go e adicione a definição mais simples possível da função Soma para fazer o teste compilar e, idealmente, passar:

package main

func Soma(a, b int) int {
    return 0 // Comece com algo que compile, mesmo que errado
}

Salve o arquivo e rode go test novamente:

--- FAIL: TestSoma (0.00s)
    soma_test.go:10: Soma(2, 2) = 0; esperado 4
FAIL
exit status 1
FAIL    meuprojeto_tdd  0.001s

Agora o código compila, mas o teste ainda falha (vermelho), porque Soma(2,2) retorna 0, mas esperávamos 4. Isso é bom, significa que nosso teste está verificando o comportamento correto.

Vamos corrigir a função Soma para que ela faça o que o teste espera:

No soma.go:

package main

func Soma(a, b int) int {
    return a + b // A implementação correta e mínima
}

Salve e rode go test novamente:

PASS
ok      meuprojeto_tdd  0.001s

Sucesso! O teste passou. Estamos no "verde".

Passo 3: REFACTOR - Melhore o Código (se necessário)

Neste exemplo simples, a função Soma já está bem clara e concisa. Não há muito o que refatorar no código de produção. No entanto, poderíamos pensar em melhorar o teste.

Por exemplo, e se quiséssemos testar mais alguns casos?

No soma_test.go:

package main

import "testing"

func TestSoma(t *testing.T) {
    testes := []struct {
        a, b, esperado int
    }{
        {2, 2, 4},
        {3, 5, 8},
        {-1, 1, 0},
        {0, 0, 0},
    }

    for _, tt := range testes {
        resultado := Soma(tt.a, tt.b)
        if resultado != tt.esperado {
            t.Errorf("Soma(%d, %d) = %d; esperado %d", tt.a, tt.b, resultado, tt.esperado)
        }
    }
}

Esta é uma técnica comum em Go chamada "table-driven tests" (testes orientados a tabelas). Definimos uma série de casos de teste (entradas e saídas esperadas) e iteramos sobre eles.

Rode go test novamente para garantir que tudo continua passando:

PASS
ok      meuprojeto_tdd  0.001s

Excelente! Refatoramos nosso teste para cobrir mais cenários, e ele continua verde.

Integração com VS Code:

A extensão Go para VS Code oferece ótimas integrações:

  • "Run test" e "Debug test" Code Lenses: Acima das suas funções TestXxx, você verá pequenos links de texto "run test" e "debug test". Clicar neles executa ou depura o teste específico.
  • Test Explorer: Na barra lateral do VS Code, há um ícone de frasco de Erlenmeyer (🧪). Ele abre o Test Explorer, que descobre e lista seus testes, permitindo que você os execute individualmente ou todos de uma vez, e veja os resultados visualmente.
  • Geração de Testes Unitários: O VS Code pode ajudar a gerar esqueletos de testes. Se você tiver uma função MinhaFuncao em meuarquivo.go, pode clicar com o botão direito sobre ela e procurar por opções como "Go: Generate Unit Tests for Function".

Pensando a Aplicação de Modo Testável: Como Começar uma Feature pelos Testes​

O exemplo da soma é simples. Como aplicar isso a uma feature mais complexa?

  1. Entenda o Requisito Mínimo: Qual é a menor parte da funcionalidade que você pode implementar e testar? Não tente construir tudo de uma vez.

  2. Defina a Interface (Mentalmente ou no Teste): Como você, como usuário dessa nova funcionalidade (ou o código que a chamará), espera interagir com ela? Quais entradas ela receberá? O que ela deve retornar? Quais efeitos colaterais ela deve ter?

  3. Escreva o Teste para o Caso Mais Simples (ou um Caso de Borda):

    • Exemplo: Se você está criando uma função que valida um email:
      • Teste 1 (RED): TestValidaEmail_ComEmailValido - Chame ValidaEmail("teste@exemplo.com") e espere true (ou nenhum erro).
      • Implemente o mínimo em ValidaEmail para isso passar (GREEN).
      • Refatore (REFACTOR).
      • Teste 2 (RED): TestValidaEmail_ComEmailInvalidoSemArroba - Chame ValidaEmail("testeexemplo.com") e espere false (ou um erro específico).
      • Altere ValidaEmail para fazer este novo teste passar, sem quebrar o anterior (GREEN).
      • Refatore (REFACTOR).
      • Continue com outros casos: email sem ponto, email com caracteres especiais inválidos, etc.

  4. Construa a Funcionalidade Incrementalmente: Cada ciclo Red-Green-Refactor adiciona um pequeno pedaço do comportamento esperado. Os testes guiam o design e a implementação.

Por que isso ajuda a pensar de modo testável?

  • Foco no Comportamento: Você define o o quê antes do como.
  • Isolamento: Para testar uma unidade de código, ela precisa ser razoavelmente isolada. Se sua função faz 10 coisas diferentes e depende de 5 outras partes complexas do sistema que não podem ser facilmente controladas no teste, você naturalmente será incentivado a quebrar essa função em partes menores e mais gerenciáveis, cada uma com seus próprios testes.
  • Dependências Explícitas: Ao tentar escrever um teste, você rapidamente percebe quais são as dependências externas da sua unidade de código (outros pacotes, serviços, bancos de dados). Isso o força a pensar em como fornecer essas dependências de uma forma que possa ser controlada durante o teste (o que nos levará ao tópico de mocks).

Esta "receita de bolo" é o ponto de partida. A prática levará à maestria. No próximo capítulo, vamos abordar como lidar com dependências externas, como bancos de dados e chamadas de API, usando mocks e stubs, um aspecto crucial para manter seus testes unitários rápidos e confiáveis.

Lidando com Dependências Externas: Mocks e Stubs​

No mundo real, suas funções raramente vivem isoladas. Elas frequentemente interagem com dependências externas, como bancos de dados, APIs de terceiros, sistemas de arquivos, filas de mensagens, ou até mesmo outras partes do seu próprio sistema que são complexas demais para serem incluídas em um teste unitário.

É aqui que entram os Mocks e Stubs, técnicas essenciais para manter seus testes unitários focados, rápidos e confiáveis. O TDD incentiva o uso dessas técnicas porque, ao escrever o teste primeiro, você é forçado a pensar em como isolar a unidade de código que está testando.

Por que precisamos isolar dependências?

  • Rapidez: Testes unitários devem ser rápidos. Se cada teste precisar se conectar a um banco de dados real ou fazer uma chamada de rede, eles se tornarão lentos e impraticáveis para rodar com frequência.
  • Confiabilidade (Determinismo): Testes devem produzir o mesmo resultado toda vez que são executados, dado o mesmo código. Dependências externas podem introduzir variabilidade (o banco de dados pode estar offline, a API pode retornar um erro inesperado, dados podem mudar).
  • Foco: Um teste unitário deve testar apenas uma unidade de código. Se o teste falha, você deve saber que o problema está na unidade testada, e não em uma de suas dependências.
  • Facilidade de Simular Cenários: É mais fácil simular comportamentos específicos de uma dependência (como um erro de banco de dados ou uma resposta específica de uma API) usando um mock do que tentando configurar o ambiente real para esses cenários.

O que são Mocks e Stubs?

Embora os termos sejam às vezes usados de forma intercambiável, há uma distinção sutil:

  • Stubs: Fornecem respostas pré-definidas para chamadas feitas durante o teste. Eles são usados quando você não precisa verificar as interações com a dependência, apenas garantir que sua unidade de código se comporta corretamente com as respostas fornecidas pelo stub. Por exemplo, um stub de banco de dados pode sempre retornar um usuário específico quando solicitado.

  • Mocks: São objetos que simulam o comportamento de dependências reais de uma forma controlada. Além de fornecerem respostas, os mocks também podem ser programados para verificar as interações que a unidade de código sob teste faz com eles. Por exemplo, um mock de um serviço de email pode verificar se o método EnviarEmail foi chamado com os parâmetros corretos.

Em Go, frequentemente usamos interfaces para facilitar a criação de mocks e stubs. Se sua unidade de código depende de uma interface em vez de uma implementação concreta, você pode facilmente fornecer uma implementação falsa (um mock ou stub) durante os testes.

Exemplo Prático: Mockando um Repositório de Banco de Dados em Go

Imagine que temos um serviço que busca um usuário. Ele depende de um RepositorioDeUsuarios para interagir com o banco de dados.

1. Defina a Interface da Dependência:

// arquivo: repositorio_usuarios.go
package main

type Usuario struct {
    ID   int
    Nome string
}

// RepositorioDeUsuarios define as operações que esperamos de um repositório de usuários.
type RepositorioDeUsuarios interface {
    BuscarPorID(id int) (Usuario, error)
}

2. Implemente o Serviço que Usa a Interface:

// arquivo: servico_usuarios.go
package main

import "fmt"

// ServicoDeUsuarios usa um RepositorioDeUsuarios para realizar suas operações.
type ServicoDeUsuarios struct {
    repo RepositorioDeUsuarios
}

// NovoServicoDeUsuarios cria uma nova instância de ServicoDeUsuarios.
func NovoServicoDeUsuarios(r RepositorioDeUsuarios) *ServicoDeUsuarios {
    return &ServicoDeUsuarios{repo: r}
}

// EncontrarUsuario busca um usuário pelo ID usando o repositório.
func (s *ServicoDeUsuarios) EncontrarUsuario(id int) (Usuario, error) {
    usuario, err := s.repo.BuscarPorID(id)
    if err != nil {
        // Poderíamos ter lógicas mais complexas aqui, como retornar um erro customizado
        return Usuario{}, fmt.Errorf("serviço: usuário não encontrado: %w", err)
    }
    return usuario, nil
}

3. Crie um Mock para RepositorioDeUsuarios no seu arquivo de teste:

// arquivo: servico_usuarios_test.go
package main

import (
    "errors"
    "testing"
)

// MockRepositorioDeUsuarios é uma implementação mock da interface RepositorioDeUsuarios.	ype MockRepositorioDeUsuarios struct {
    BuscarPorIDFunc func(id int) (Usuario, error) // Permite definir o comportamento do mock
}

// BuscarPorID implementa a interface para o mock.
func (m *MockRepositorioDeUsuarios) BuscarPorID(id int) (Usuario, error) {
    if m.BuscarPorIDFunc != nil {
        return m.BuscarPorIDFunc(id)
    }
    // Comportamento padrão se nenhuma função for definida (pode ser útil)
    return Usuario{}, errors.New("mock: BuscarPorIDFunc não implementado")
}

func TestServicoEncontrarUsuario_Sucesso(t *testing.T) {
    // RED: Definir o comportamento esperado do mock
    mockRepo := &MockRepositorioDeUsuarios{
        BuscarPorIDFunc: func(id int) (Usuario, error) {
            if id == 1 {
                return Usuario{ID: 1, Nome: "Usuário Teste"}, nil
            }
            return Usuario{}, errors.New("usuário não encontrado no mock")
        },
    }

    servico := NovoServicoDeUsuarios(mockRepo)

    usuario, err := servico.EncontrarUsuario(1)

    // GREEN: Verificar o resultado
    if err != nil {
        t.Fatalf("Esperado nenhum erro, mas obteve: %v", err)
    }
    if usuario.Nome != "Usuário Teste" {
        t.Errorf("Nome do usuário esperado 'Usuário Teste', mas obteve '%s'", usuario.Nome)
    }
    // REFACTOR: O teste já está razoavelmente limpo.
}

func TestServicoEncontrarUsuario_ErroRepositorio(t *testing.T) {
    // RED
    mockRepo := &MockRepositorioDeUsuarios{
        BuscarPorIDFunc: func(id int) (Usuario, error) {
            return Usuario{}, errors.New("erro simulado do repositório")
        },
    }

    servico := NovoServicoDeUsuarios(mockRepo)

    _, err := servico.EncontrarUsuario(99)

    // GREEN
    if err == nil {
        t.Fatal("Esperado um erro, mas não obteve nenhum")
    }
    // Poderíamos verificar a mensagem de erro específica se quiséssemos
    // if !strings.Contains(err.Error(), "erro simulado do repositório") { ... }
}

Explicação do Mock:

  • MockRepositorioDeUsuarios implementa a interface RepositorioDeUsuarios.
  • BuscarPorIDFunc é um campo de função no mock. Isso nos permite injetar um comportamento específico para o método BuscarPorID em cada teste.
  • No teste TestServicoEncontrarUsuario_Sucesso, configuramos o mock para retornar um usuário específico quando BuscarPorID(1) é chamado.
  • No teste TestServicoEncontrarUsuario_ErroRepositorio, configuramos o mock para sempre retornar um erro.

Esta abordagem, conhecida como Injeção de Dependência (passar as dependências para um objeto em vez de ele mesmo criá-las), é fundamental para a testabilidade e é naturalmente promovida pelo TDD.

Ferramentas de Mock em Go:

Embora mocks manuais como o acima sejam comuns e educativos, para interfaces mais complexas, você pode usar ferramentas que geram mocks automaticamente, como:

  • gomock (do Google): Uma biblioteca popular para gerar mocks a partir de interfaces.
  • testify/mock: Parte da popular suíte testify, que também oferece muitas outras utilidades para testes.

O VS Code geralmente tem boa integração com essas ferramentas se elas estiverem instaladas no seu ambiente Go.

Testes Unitários vs. Testes de Integração: Entendendo a Diferença​

Esta é uma distinção crucial, especialmente quando lidamos com dependências como bancos de dados e filas.

  • Testes Unitários:

    • Foco: Testam a menor unidade de código isoladamente (uma função, um método, uma classe/struct).
    • Dependências: Dependências externas são substituídas por mocks ou stubs.
    • Velocidade: Muito rápidos.
    • Escopo: Verificam a lógica interna da unidade.
    • Quando usar: Sempre! São a base da pirâmide de testes.
    • Exemplo: O teste do ServicoDeUsuarios com o MockRepositorioDeUsuarios é um teste unitário.

  • Testes de Integração:

    • Foco: Testam a interação entre duas ou mais unidades/componentes do sistema, ou entre seu sistema e uma dependência externa real (como um banco de dados ou uma API de terceiros).
    • Dependências: Usam dependências reais ou ambientes de teste que simulam de perto o real.
    • Velocidade: Mais lentos que os testes unitários.
    • Escopo: Verificam se os componentes se comunicam corretamente e se a integração com sistemas externos funciona como esperado.
    • Quando usar: Com moderação. São importantes para garantir que as "costuras" do seu sistema funcionam, mas não precisam cobrir todos os cenários que os testes unitários já cobrem.
    • Exemplo: Um teste que configura um banco de dados de teste real (por exemplo, um Docker container com PostgreSQL), insere dados, chama o ServicoDeUsuarios (que usa uma implementação real do RepositorioDeUsuarios que se conecta a este banco) e verifica se os dados corretos são retornados do banco.

Por que a Diferença é Importante para Bancos de Dados e Filas?

  • Testes Unitários para a Lógica de Negócio: Sua lógica de negócio (o que acontece no ServicoDeUsuarios, por exemplo) deve ser testada unitariamente, mockando o acesso ao banco de dados ou à fila. Isso garante que sua lógica está correta independentemente da infraestrutura.
  • Testes de Integração para a Camada de Acesso a Dados/Filas: Você também precisará de alguns testes de integração para garantir que sua implementação real do RepositorioDeUsuarios consegue se comunicar corretamente com o banco de dados (queries SQL estão corretas, mapeamento de dados funciona) ou que seu produtor/consumidor de mensagens interage corretamente com a fila.

A Pirâmide de Testes:

Pense em uma pirâmide:

  • Base (Larga): Muitos Testes Unitários (rápidos, baratos, focados).
  • Meio: Menos Testes de Integração (mais lentos, mais caros).
  • Topo (Estreito): Pouquíssimos Testes End-to-End (E2E) ou de UI (os mais lentos e caros, testam o sistema todo como um usuário faria).

O TDD foca principalmente na base e no meio dessa pirâmide.

Ao entender e aplicar mocks e a distinção entre tipos de teste, você estará bem equipado para construir aplicações Go robustas e testáveis, mesmo quando elas interagem com sistemas complexos.

Para aprofundar seus conhecimentos em TDD, Golang e boas práticas de teste, selecionamos alguns recursos em português que podem ser muito úteis, especialmente para quem está começando:

Conceitos Fundamentais de TDD:

  1. O que é TDD: descubra o que significa, como funciona e vantagens (YouTube - Didática Tech):

  2. TDD: Test Driven Development ou Desenvolvimento Guiado por Testes (Medium - Manoel Camillo):

  3. Test-driven development – Wikipédia, a enciclopédia livre:

TDD com Golang (Tutoriais e Exemplos Práticos):

  1. Aprenda Go com Testes (GitBook - Tradução por Lari Teles e outros):

    • Link: https://larien.gitbook.io/aprenda-go-com-testes/
    • Descrição: Este é, possivelmente, o melhor recurso em português para aprender Go através do TDD. É um livro online completo, traduzido do famoso "Learn Go with Tests". Ele guia você desde a instalação do Go até a criação de uma aplicação completa, sempre com foco em testes. Cobre desde o básico até concorrência, mocks, e muito mais. Altamente recomendado!

  2. The Go Show #3: Test Driven Development (TDD) in Go (YouTube - The Go Show):

    • Link: https://www.youtube.com/watch?v=yME2peeAxeE
    • Descrição: Embora o áudio principal seja em inglês, este canal costuma ter legendas e é uma boa demonstração prática de TDD em Go. Verifique a disponibilidade de legendas em português.

  3. Golang: TDD na prática (YouTube - Full Cycle):

    • Link: (Pesquisar no YouTube por "Full Cycle TDD Golang" - os links diretos podem mudar, mas o canal Full Cycle tem excelentes conteúdos práticos sobre Go).
    • Descrição: O canal Full Cycle frequentemente publica vídeos práticos e de alta qualidade sobre desenvolvimento com Go, incluindo TDD. Vale a pena explorar os vídeos deles.

Configuração e Uso do VS Code para Desenvolvimento Go:

  1. VSCode para Golang [2022] Configuração Simples! (YouTube - Code Go):

  2. Documentação Oficial da Extensão Go para VS Code:

    • Link: (Acesse diretamente pela aba de Extensões no VS Code, procure por "Go" e clique na extensão para ver sua documentação detalhada).
    • Descrição: A documentação oficial é sempre a fonte mais atualizada sobre os recursos da extensão, incluindo depuração de testes, code navigation, etc.

Dicas Adicionais:

  • Pratique, Pratique, Pratique: A melhor forma de internalizar o TDD é praticando. Comece com problemas pequenos e vá aumentando a complexidade.
  • Leia Código com Testes: Explore projetos open-source em Go no GitHub que utilizam TDD. Observar como outros desenvolvedores escrevem testes pode ser muito instrutivo.
  • Não Tenha Medo de Perguntar: Se tiver dúvidas, converse com seus colegas de equipe mais experientes. A troca de conhecimento é fundamental.

Esperamos que estes recursos ajudem você a se aprofundar no mundo do TDD e a se tornar um desenvolvedor Go ainda mais eficaz e confiante!

Conclusão: Sua Jornada com TDD Apenas Começou​

Parabéns por chegar até aqui! Esperamos que este manual tenha fornecido uma base sólida e prática para você iniciar sua jornada com o Desenvolvimento Guiado por Testes (TDD) utilizando Golang.

Lembre-se que o TDD é mais do que uma técnica de teste; é uma disciplina de design de software que, com a prática, se tornará uma segunda natureza. Os benefícios em termos de qualidade de código, manutenibilidade, redução de bugs e confiança para realizar alterações são imensos.

Os principais pontos que abordamos e que gostaríamos que você levasse consigo são:

  • O ciclo Red-Green-Refactor como seu mantra diário.
  • A importância de pensar na testabilidade desde o início do desenvolvimento de qualquer feature.
  • Como escrever testes unitários eficazes em Go, utilizando o pacote testing.
  • A necessidade de isolar dependências (como bancos de dados e filas) utilizando mocks e stubs, e como as interfaces em Go facilitam isso.
  • A diferença crucial entre testes unitários e testes de integração, e quando aplicar cada um.

Não se preocupe se, no começo, o processo parecer um pouco mais lento. Com a prática, você ganhará fluidez e perceberá que o TDD, na verdade, pode acelerar o desenvolvimento a longo prazo, evitando retrabalho e longas sessões de depuração.

Utilize os exemplos e os links fornecidos como ponto de partida para sua exploração contínua. A comunidade Go é vasta e rica em recursos.

Estamos aqui para apoiar seu crescimento. Não hesite em discutir suas experiências, dúvidas e aprendizados com TDD com seus colegas e líderes de equipe.

Bem-vindo(a) novamente, e feliz TDD!