Introdução

O desenvolvimento orientado a testes é um método eficaz para garantir um código bem testado e refatorável. A ideia básica é que você comece o desenvolvimento escrevendo testes. Esses testes documentam claramente as expectativas e criam uma rubrica para uma implementação bem-sucedida. Quando feito corretamente, você pode definir claramente a entrada/saída esperada de uma função antes de escrever qualquer código. Isso traz alguns benefícios imediatos:

• Você considera cuidadosamente a interface para interagir com seu código e projeta-a para ser testável
• Quando você começa a escrever código, seu fluxo não é interrompido por testes manuais ou pela lógica de execução para prever o resultado. Em vez disso, basta executar os testes
• Fazer uma aprovação no teste torna-se uma meta satisfatória de ser alcançada. Dividir o processo em uma série de marcos bem definidos e alcançáveis ​​torna o trabalho mais agradável
• Evite a preguiça pós-implementação e o excesso de confiança que podem impedir você de testar seu código

Agora que você está convencido dos benefícios, você pode começar com o desenvolvimento orientado a testes (TDD) seguindo estas etapas:

1. Escrever ou modificar testes
2. Verifique se o teste falhou
3. Escreva a quantidade mínima de código para fazer os testes passarem

Essas etapas são seguidas em um ciclo para que você sempre adicione mais testes para desafiar a implementação atual.

A última etapa, que especifica a escrita da quantidade mínima de código, é onde as coisas podem ficar entediantes se seguidas rigidamente. É importante entender por que essa regra existe antes de determinar quando é apropriado desviar-se dela.

Exemplo simples

Você está encarregado de implementar a função Add(x, y int) int. Antes de passar para a implementação e retornar x y, escreva o teste mais simples: 1 1 == 2. Então, qual é a implementação mais simples que passaria no teste? É apenas return 2. Agora seus testes passam!

Neste ponto, você percebe que precisa de mais testes, então acelera o ritmo e adiciona mais alguns:

• 1 2 == 3
• 100 5 == 105

Agora seus testes falham, então você precisa corrigir a implementação. Você não pode simplesmente retornar 3 ou 105 desta vez, então você precisa encontrar uma solução que funcione para todos os testes. Isso leva à implementação: return x y.

Embora isso pareça muito tedioso no exemplo trivial, a adesão estrita a esse método fez com que você escrevesse vários testes em vez de apenas confiar em sua implementação. É claro que sua ideia inicial de retornar x y teria funcionado, mas o objetivo é treinar novamente para confiar em testes em vez de em seu próprio entendimento do código. No mundo real, você não é o único trabalhando nesse trecho de código e inevitavelmente esquecerá os detalhes da implementação. Este processo força você a escrever mais testes e pensar em mais maneiras de quebrar a implementação simples.

Eventualmente, você ganhará experiência e aprenderá a encontrar o equilíbrio que funciona nos diferentes cenários que encontrar. Você voltará à implementação de recursos em velocidade total e descobrirá que tem menos bugs e escreverá mais código de manutenção.

TDD passo a passo para uma API HTTP

Vamos entrar em um exemplo mais complicado usando TDD para uma API HTTP REST. Este guia passo a passo usa minha estrutura Go, babyapi, mas os conceitos podem ser aplicados em qualquer lugar.

babyapi usa genéricos para criar uma API CRUD completa em torno de estruturas Go, tornando muito fácil criar uma API REST completa e uma CLI de cliente. Além disso, o pacote babytest fornece algumas ferramentas para a criação de testes de tabelas de API ponta a ponta. Usar TDD no nível da API permite testar completamente as camadas HTTP e de armazenamento de uma nova API ou recurso de uma só vez.

Isenção de responsabilidade: como o babyapi lida com a maior parte da implementação e também é usado para gerar padrões de teste, tecnicamente não estamos começando com o TDD. No entanto, veremos como isso é benéfico ao adicionar suporte para solicitações PATCH à nossa API.

1. Crie um novo projeto Go
   

2. Crie main.go inicial usando o exemplo simples do babyapi
   

3. Use a CLI para gerar um padrão de teste
   

4. Implemente cada teste preenchendo os espaços reservados com o JSON esperado
   

5. Faça os testes e veja se eles passam!

6. Como PUT é idempotente, exige que todos os campos sejam incluídos. Para evitar isso, queremos adicionar suporte para alternar solicitações concluídas com PATCH. Começamos adicionando um teste simples para saber como esperamos que esse recurso seja
   

7. Este teste falha porque babyapi não suporta PATCH por padrão. Podemos consertar isso implementando Patch para a estrutura TODO. Como definimos nosso recurso com dois testes, nossa implementação mais simples não é apenas definir Completed = true e temos que usar o valor da solicitação
   

8. Agora podemos alterar o status Concluído de um TODO, mas ainda não podemos usar PATCH para modificar outros campos como mostra este novo conjunto de testes
   

9. Atualize o patch para definir os campos restantes
   

10. Nossos testes ainda falham, pois sempre atualizamos o TODO com os campos de solicitação, mesmo que estejam vazios. Corrija isso atualizando a implementação para verificar valores vazios
    

11. O novo teste UpdateWithPatch foi aprovado, mas nossos testes anteriores falharam. Como alteramos Completed para *bool, TODOs criados com um valor vazio serão exibidos como null
    

12. Implemente Render para TODO para que possamos tratar nil como falso
    

A implementação do recurso PATCH com desenvolvimento orientado a testes resultou em um conjunto robusto de testes e um recurso bem implementado. Como começamos definindo a entrada e a saída esperadas de uma solicitação PATCH nos testes, foi fácil ver os problemas causados ​​pela não verificação de valores vazios na solicitação. Além disso, nossos testes pré-existentes foram capazes de proteger contra alterações significativas ao alterar o tipo de Concluído para *bool.

Conclusão

O desenvolvimento orientado a testes é uma abordagem eficaz para criar código totalmente testado e correto. Começando com os testes em mente, podemos garantir que cada parte do código seja projetada para ser testável, em vez de deixar os testes serem uma reflexão tardia.

Se você está hesitante em adotar o TDD, aqui estão algumas ideias para começar:

• Experimente em cenários simples onde a entrada/saída de uma função é clara e a implementação não é excessivamente complicada. Você pode escrever um teste de tabela robusto para a variedade de entradas/saídas que podem ser encontradas. Ter uma visão clara dos diferentes cenários pode simplificar a implementação
• Se estiver corrigindo um novo bug, você já identificou uma lacuna em seus testes. Comece escrevendo um teste que teria identificado esse bug em primeiro lugar. Em seguida, faça este teste passar sem quebrar nenhum teste existente.
• Semelhante ao exemplo do babyapi, você pode usar TDD para testes de API de alto nível. Depois de ter uma definição da solicitação/resposta esperada, você pode retomar seu fluxo normal de desenvolvimento para partes da implementação mais detalhadas

Mesmo que o TDD não seja uma boa opção para a maneira como você escreve código, ainda é uma ferramenta poderosa para se ter em mãos. Eu encorajo você a pelo menos dedicar algum tempo para experimentá-lo e ver como isso afeta seu processo de desenvolvimento.