O que é TDD (Test-Driven Development)?

Kent Beck desenvolveu TDD no contexto de Extreme Programming no fim dos anos 1990, conforme a descrição de Martin Fowler. O ciclo vermelho, verde e refatora tornou-se sua forma mais conhecida. A técnica é uma prática de engenharia, não um evento obrigatório do Scrum nem uma garantia automática de ausência de defeitos.

TDD, Test-Driven Development, é uma disciplina de programação em que um teste automatizado pequeno antecede o código de produção que o fará passar. O ciclo é conhecido como vermelho, verde e refatora: ver a falha esperada, implementar apenas o suficiente e melhorar a estrutura mantendo comportamento. Martin Fowler atribui o desenvolvimento da técnica a Kent Beck, no contexto de Extreme Programming no fim dos anos 1990. A prática relaciona programação, testes e design em ciclos curtos.

Comece por um comportamento. Faça uma lista de casos que a funcionalidade precisa atender. Escolha o menor caso útil e escreva um teste que expresse o resultado esperado. Um teste que falha por erro de configuração não é o mesmo que falhar porque o comportamento ainda não existe. Confirmar essa distinção protege a lógica do ciclo. Testes devem ter nomes e exemplos claros para outra pessoa compreender o contrato observado.

Veja o vermelho. Execute o teste antes de implementar. A falha mostra que ele pode detectar a ausência do comportamento. Se já passa, talvez esteja testando outra coisa ou o comportamento já exista; esclareça antes de continuar. Não acrescente muitos testes falhando de uma vez para depois desenvolver tudo: o retorno rápido ajuda a localizar a causa e limita o tamanho da decisão de design.

Chegue ao verde. Escreva o mínimo de código necessário para satisfazer o teste, sem antecipar recursos futuros. “Mínimo” não significa publicar código descuidado: é uma etapa curta do ciclo, seguida por melhoria. Em alguns casos, uma implementação simples parece trivial, mas permite avançar para o próximo exemplo que exigirá generalização. Não crie abstrações para possibilidades que ainda não foram demonstradas por necessidade real.

Refatore com proteção. Com a suíte verde, elimine duplicação, melhore nomes e ajuste estrutura sem alterar comportamento observável. Rode os testes novamente. Refatorar não é acrescentar nova função; se um comportamento novo é necessário, volte ao vermelho com outro teste. Uma suíte rápida e confiável dá feedback, mas não prova ausência de defeitos em tudo o que não foi coberto.

Escolha a fronteira do teste. Um teste de unidade pode exercitar uma função ou um componente com dependências controladas. Testes de integração verificam interação com banco, rede ou outros serviços, com custo e velocidade diferentes. TDD pode ocorrer em vários níveis, mas um ciclo lento e frágil dificulta seu uso diário. Evite mocks que apenas repetem detalhes de implementação: eles podem passar enquanto o comportamento real falha.

Use exemplos para desenhar interface. Ao escrever o teste antes, a pessoa desenvolvedora consome a API antes de construí-la. Isso pode revelar nomes confusos, dependências difíceis de configurar ou responsabilidades excessivas. A melhoria de design não acontece automaticamente; requer escolhas e refatoração. Um código coberto por muitos testes pode continuar complicado se os testes só congelam sua forma atual.

Conecte ao produto. Critérios de aceitação e conversas com stakeholders ajudam a escolher comportamentos valiosos; TDD transforma uma parte desses comportamentos em feedback automatizado de engenharia. A técnica não substitui testes exploratórios, segurança, desempenho, acessibilidade ou validação de valor com usuários. Um teste verde comprova uma condição especificada, não que a condição era a certa para o produto.

Trate legado com pragmatismo. Em um sistema sem testes, talvez seja necessário criar testes de caracterização antes de alterar código. Primeiro descreva o comportamento atual que deve ser preservado; depois introduza mudança em passos menores. Às vezes a dependência rígida exige isolar uma parte do sistema. TDD não obriga reescrever tudo; pode começar em uma nova regra ou correção bem delimitada.

Avalie o efeito real. Observe defeitos escapados, facilidade de mudança, tempo de feedback e clareza dos testes. Medir apenas percentual de cobertura incentiva exercícios que não protegem o comportamento importante. A prática exige treinamento e colaboração, especialmente para escolher bons exemplos e refatorar com segurança. Se o ciclo vira ritual mecânico, investigue tamanho dos passos, qualidade da suíte e entendimento do domínio.

Exemplo hipotético: um sistema calcula desconto para assinaturas. A equipe começa com o caso “assinatura ativa com cupom válido recebe desconto de 10%”, escreve o teste e vê falha porque a regra não existe. Implementa a condição mínima e obtém verde. Em seguida, melhora o nome da função e remove duplicação, mantendo o teste verde. Os números são ilustrativos, não regra de negócio da K21.

O próximo teste descreve cupom vencido sem desconto. Ele falha e obriga a distinguir validade do cupom. Outro exemplo cobre limite máximo de desconto. A implementação emerge de casos observáveis, enquanto a equipe discute com produto o que deve acontecer em situações não definidas. Uma dúvida sobre reembolso parcial não é resolvida inventando um teste: precisa de decisão de domínio.

Ao final, testes automatizados apoiam mudanças futuras, mas a equipe ainda realiza verificação de integração e exploração da experiência. O exemplo mostra a sequência pequena de feedback, não a promessa de que TDD sozinho garante qualidade completa.

Em TDD, o teste antecede o próximo pedaço de código e ajuda a definir a interface e o comportamento. Testar depois também pode detectar problemas, mas não proporciona o mesmo ciclo de design dirigido por exemplos. Ambas as abordagens dependem da qualidade dos testes. A escolha não elimina teste exploratório, integração e validação com usuários; elas respondem a perguntas diferentes.

Cursos K21 recomendados