Quase sempre que tive acesso a parte de teste unitários ela vinha de algo já pronto. Eu sentia falta de algo que explicasse o início, o por que, enfim… como começar?
O Ciclo Sagrado: Red, Green, Refactor
O coração do TDD bate no ritmo de três passos fundamentais. Se você pular um deles, não está fazendo TDD, está apenas escrevendo testes depois (o que também é importante, mas é outra história).
1. Red (Vermelho): Escreva um teste que falha
Você começa escrevendo um teste para a funcionalidade que deseja implementar. Como a funcionalidade ainda não existe, obviamente o teste vai falhar.
- O objetivo aqui é ver o teste ficar vermelho. Se o teste passar de primeira, tem algo errado: ou o seu teste é inútil ou a funcionalidade já estava implementada.
2. Green (Verde): Faça o teste passar
Agora, você escreve o mínimo necessário de código de produção para fazer o teste passar.
- Não se preocupe com código elegante, padrões arquiteturais complexos ou otimizações mirabolantes neste momento. O foco único e exclusivo é passar no teste. Se a solução mais porca e rápida resolver, que assim seja (por enquanto).
3. Refactor (Refatorar): Melhore o código
Com o teste verde, você tem uma rede de segurança. Agora é hora de limpar a casa.
- Você pode remover duplicações, melhorar nomes de variáveis, aplicar padrões de projeto e deixar o código limpo e legível, garantindo que o teste continue verde ao final de cada alteração.
Por que você deveria se importar?
Se você parar para pensar, o desenvolvimento tradicional costuma funcionar assim: codificamos por horas, rodamos a aplicação manualmente, clicamos em dez botões diferentes para ver se quebrou algo e, no fim, rezamos para que funcione em produção.
Aplicando TDD, você ganha:
- Feedback imediato: Você sabe em segundos se o seu código faz o que deveria fazer.
- Menos bugs em produção: Como você pensa nos casos de borda e cenários de erro antes de codar, a sua lógica nasce muito mais robusta.
- Documentação viva: Os testes servem como especificação executável do seu sistema. Qualquer pessoa (inclusive você daqui a seis meses) consegue entender o que o código faz lendo os testes.
- Coragem para refatorar: Mudar código legado ou grande dá medo. Com uma suíte de testes robusta guiada por TDD, você refatora com confiança.
Erros comuns ao começar com TDD
Quando estamos aprendendo, é normal cair em algumas armadilhas clássicas:
- Querer testar tudo de uma vez: TDD é sobre pequenos passos. Se o seu teste exige 50 linhas de setup, você está tentando abraçar o mundo. Quebre o problema em pedaços menores.
- Escrever testes complexos: Se o seu teste precisa de mock em cima de mock, banco de dados relacional completo e API externa para rodar uma lógica simples, o design do seu código está acoplado demais. O TDD ajuda a perceber isso.
- Desistir no primeiro obstáculo: No começo, parece que o TDD dobra o seu tempo de desenvolvimento. É verdade, a curva de aprendizado inicial é frustrante. Mas a longo prazo, o tempo economizado em debugging compensa cada segundo investido.
Vídeo
Eu gravei em vídeo um minicurso, e nessa primeira parte compartilho essa parte teórica do TDD. Da forma como eu penso que deve ser explicado, desde o início!
Me inspirei no curso online do ITA (Instituto Técnológico da Aeronáutica) TDD – Desenvolvimento de Software Guiado por Testes ministrado por Eduardo Guerra, disponibilizado na plataforma Coursera.
Resumo da Ópera
O TDD não é uma bala de prata e nem deve ser usado como religião dogmática para absolutamente 100% do seu sistema. No entanto, dominar a teoria e praticar o ciclo Red-Green-Refactor vai mudar completamente a forma como você enxerga a construção de software.
Escrever código guiado por testes é sobre clareza de pensamento. É saber exatamente para onde você está indo antes de dar o primeiro passo.
E você? Já aplica TDD no seu dia a dia ou acha que é perda de tempo? Deixa aqui nos comentários a sua experiência!