O que é ?

“ Técnica de desenvolvimento cujo processo é formado por pequenas iterações. Onde os testes são codificados primeiro.”

Com TDD o desenvolvedor deve pensar em escrever testes antes de escrever código.

Seus testes irão guiar o desenvolvimento do sistema.

O TDD vem do conceito Test Frist Programming do XP (Extreme Programming), entretanto ganhou tanto interesse que vem sendo utilizado independente das Metodologias Ágeis como o XP.

Qual é o nosso cenário atual ?

1. Bugs,
2. Difícil manutenção,
3. Produtividade Baixa.

Ciclo da Morte para desenvolvimento de Software

Por que TDD ?

Garantir a existência de testes unitários completos e atualizados;

Diminuir a quantidade de erros por linha de código;

Testes unitários são documentações executáveis;

Direcionar o projeto a ser mais desacoplado, flexível, modular com métodos coesos e extensíveis;

Tornar o Incerto em algo Familiar;

Proporcionar Maior Valor ao sistema e Menor esforço aos desenvolvedores e a equipe com um todo.

Objetivo do TDD

• “Clean Code That Works”
• Código limpo que funciona.

Mantra do TDD (Red – Green – Refactor)

1. Codifique o teste;
2. Faça-o compilar e executar (Não deve passar  – Vermelho);
3. Implemente o requisito e faça o teste passar (Verde);
4. Refatore o Código.

Regras Fundamentais do TDD

Sempre inicie com uma lista de testes: No TDD, não saímos codificando. Antes de iniciar a construção de qualquer coisa, elabore uma lista de testes inicial. Caso seja necessário, você poderá incluir mais itens na sua lista de testes mesmo depois de já ter iniciado a codificação;

Sempre inicie pelo teste mais simples: Após elaborar sua lista de testes, inicie a codificação pelo teste mais simples da sua lista. Desenvolvendo dessa forma, você não só ganha ritmo, mas também vai aprendendo de pouco a pouco sobre o problema que está resolvendo.

Comece a construção do seu código pela construção do seu teste: Desenvolvendo o teste primeiro (como preza o TDD) temos a oportunidade de tomar decisões de design das nossas classes antes mesmo de construí-las. Iniciar a construção do código pelo teste possibilita que você veja o seu código pela perspectiva de quem o utilizará, ou seja, você terá um feedback de utilização antes mesmo de codificar sua classe.

Comece o teste pela assertiva: Iniciar o teste pela assertiva é definir o objetivo do teste. Escrever a assertiva é definir aonde você quer chegar no teste, qual objetivo quer alcançar, se isso não estiver bem definido não adianta escrever o teste.

Simule até construir realmente: Sempre que possível, construa implementações falsas. Deixe para construir as implementações reais só quando for realmente necessário.

Busque o verde o mais rápido possível: Quando o teste estiver vermelho, procure fazê-lo passar o mais rápido possível, mesmo que a implementação feita não seja a mais agradável de ver. Quando o teste estiver verde, substitua a implementação feita por uma implementação mais elegante, afinal, a fase de refatoração serve para isso.

Construa somente o necessário para o teste passar: Não construa nada além do que o seus testes pedirem. Se desejar realizar alguma codificação,  escreve primeiro um teste e depois o código. TDD também exige muita disciplina.

Passos de bebê: Procure sempre dar passos pequenos durante a construção dos seus testes, evite assumir um teste muito difícil ou grande logo de cara, deixe sempre os testes mais complicados para o final.

Por que não usar?

“Estou sem tempo para testar!”

“Escrever testes demora muito!”

“Esse não é meu trabalho”

“Se compilou é porque está funcionando!”

O principal argumento dos contrários ao TDD é que supostamente o desenvolvedor irá demorar mais para desenvolver o sistema usando TDD.

Inicialmente o tempo gasto para escrita dos testes será mais alto, contudo após este início mais demorado o tempo de desenvolvimento tende a cair. Com a adição de novos recursos sua suíte de testes já estará pronta e basta ao desenvolvedor rodar seus testes para verificar se houve impacto provocado pelos novos recursos.

Conclusões

O TDD colabora para aumento da qualidade dos sistemas.

Os desenvolvedores ficam mais corajosos e confiantes ao programar.

O software cresce de forma mais ordenada e com maior qualidade de design, além de se adaptar com mais facilidade as mudanças.

 “ Desenvolvedor que não testa é como um cirurgião que não lava as mãos ”

Uncle Bob (Robert C. Martin)

Fontes:

Wikipedia;

Test Driven Development By Example, Kent Beck