Então você não faz TDD…

O quê? Você não faz TDD? Blasfêmia!

Ou será que não????

Muito já se discutiu já sobre a importância ou não de se fazer TDD, como na famosa série de conversas entre Martin Fowler, David Heinemeier Hansson e Kent Beck. Os pontos mais comuns de quem critica o TDD são:

• Testes fazem o desenvolvimento ficar mais lento;
• Construir testes é uma tarefa complexa;
• Testar pouco não traz benefícios e testar muito gera muitos testes desnecessários;
• Entre outros.

Neste artigo, tentarei dar uma definição do que é TDD e desmistificar alguns desses mitos.

Definição

TDD, também conhecido como Test-Driven Development, é uma técnica de desenvolvimento criada por Kent Beck, também pai da suíte de testes JUnit.

Essa técnica consiste da sequência de passos descrita abaixo, que forma um ciclo:

1. Escreva um teste — que falhe. Esse teste deve ser escrito antes do código que ele testa!
2. Escreva código suficiente para fazer o teste passar. Não se preocupe se o código não estiver muito bonito, o que importa neste passo é escrever o mínimo possível para implementar o requisito;
3. Identifique pontos de melhoria no código e efetue refatorações;
4. Repita o processo!

Neste momento você deve estar pensando:

Parece maluco, mas não é! Ao criar os testes primeiros, obtemos alguns benefícios, como por exemplo:

• Obtemos um feedback mais imediato de nosso desenvolvimento. Por feedback, quero dizer que, ao desenvolver um código que já possui testes, podemos realizar a codificação e já testar o código, obtendo assim um retorno mais imediato de se o nosso código está funcionando ou não;
• Pensamos mais simples nas interfaces. Ao desenvolver o teste primeiro, pensamos primeiro do ponto de vista de quem será o cliente (consumidor) do nosso código. Assim, acabamos por prevenir problemas como interfaces muito complexas ou com pouca clareza de seus objetivos;
• Temos ao final um componente resiliente a mudanças. Ao desenvolvermos os testes junto com o código que o implementa, temos ao final do desenvolvimento um código altamente robusto e expansível, dado que manutenções e mudanças evolutivas no código podem facilmente ter o seu impacto analisado através dos testes. É claro que também podemos ter esse benefício desenvolvendo os testes depois, mas desenvolvendo os testes primeiro temos a vantagem de estarmos fazendo isso mesclado ao desenvolvimento, sem ter que alocar tempo apenas para essa atividade no futuro.

Essa questão do feedback imediato é muito defendida no TDD através do conceito dos chamados baby steps, ou seja, ao desenvolver, não codificamos tudo de uma vez, mas aos poucos, em pequenos passos, construindo um pouco de cada vez, até chegarmos ao final do desenvolvimento.

Tá legal, mas e as críticas que você falou no começo? Eu não esqueci não!

Opa, calma que eu também não! Vamos agora debater as críticas que citei no começo do artigo. Algumas pessoas dizem que fazer testes deixa o desenvolvimento mais lento. Eu diria o contrário: fazer testes deixa o desenvolvimento mais rápido!

Por quê? Muito simples: ao realizarmos os testes junto com a codificação, temos um retorno mais rápido de falhas no código que só seriam detectadas mais a frente ou, pior ainda, após o código ser entregue. Isso faz com que, no final, desenvolver com testes seja mais rápido, pois não desperdiçamos tempo no futuro corrigindo problemas que não detectamos pela falta de testes.

Falamos também sobre fazer testes ser uma tarefa complexa. Geralmente, isso se atribui a tarefas relacionadas a configuração de suítes de testes, que podem compor vários tipos de bibliotecas e frameworks para mocks, fixtures etc.

É verdade que se tivermos que fazer essa configuração do zero todas as vezes isso pode se tornar uma atividade um pouco maçante, mas isso pode facilmente ser resolvido com soluções que facilitem a configuração de novos projetos, como scaffolding por exemplo.

Por fim, temos a questão do quanto devemos testar. Essa questão é de fato a que mais acarreta "disputas filosóficas" no âmbito da comunidade de tecnologia, sem que se chegue em um consenso preciso.

Na minha humilde opinião, acredito que certos tipos de código realmente não fazem sentido testar, como getters e setters e bibliotecas de terceiros, pois ou possuem lógica muito simples, ou possuem lógica que já possui os seus próprios testes implementados externamente ao projeto.

Acredito que o consenso geral é que, não se deve testar tudo, mas se testar o suficiente para garantir que todo o core das funcionalidades que compõe o código está sendo testado.

Legal, vou começar a fazer TDD e metralhar todo mundo que não faz testes primeiro!

Isso vai de encontro com o "Ou será que não?" que falei a pouco. TDD é uma ótima técnica que pode e deve ser experimentada e usada, mas temos que tomar o cuidado para não nos transformarmos em juízes inflexíveis.

Podem existir cenários em que fazer os testes primeiro não é muito prático ou mesmo aplicável. Um possível exemplo disso seria se estivéssemos desenvolvendo código que interage com um banco de dados em baixo nível, pois nesse caso, pode fazer mais sentido desenvolver o código primeiro e criar as queries SQLs, para só então desenvolver os testes para os casos de sucesso e fracasso das operações.

A regra geral, como tudo na vida é, nada em excesso é bom!

Concluindo

E assim concluo minha discussão sobre TDD. Espero ter podido passar para o leitor alguma idéia de como funciona e quais são os benefícios da técnica, bem como uma opinião de quando e como melhor aplica-la.

Até a próxima!