Confusões sobre TDD

Lendo o post sobre Desenvolvimento Orientado a Testes no blog do José Oliveira notei que ele pode gerar algumas confusões comuns para que está começando a aprender sobre esta técnica. E digo isso por experiência própria, já que levei meses até começar a desenvolver orientado a testes com alguma desenvoltura.

O texto apresenta a seguinte definição de TDD:

“…TDD é simplesmente você escrever o teste do seu programa antes de codificá-lo de fato. Teste nesse contexto seriam os testes unitários.”

Ao meu ver a essência está correta, porém talvez faltasse deixar claro que TDD não se trata apenas de escrever testes antes do código. Esta é a primeira visão que a maioria dos iniciantes têm sobre desenvolvimento orientado a testes: que basta escrever todos os testes antes e pronto. Isto é compreensível, já que escrever testes antes do código já causa um choque por si só. Porém, TDD foi definido pelo Kent Beck com a seguinte fórmula:

TDD = Test-First + Design Incremental

E a parte do design incremental ficou um pouco confusa na continuação do texto:

“…O processo de desenvolvimento usando TDD é muito simples:

1. Escolha a classe e o método que você que codificar e pense em todos os testes possíveis para ela;
2. Antes de escrever a classe, codifique os testes que você pensou….”

Seguindo estas instruções (escrever todos os testes possíveis antes) pode-se perder um pouco de um dos maiores benefícios de TDD, que é prover feedback rápido sobre o que está sendo implementado. Aí que entra o design incremental. A idéia é que a solução seja criada em pequenos passos (Baby Steps), seguindo a rotina descrita no livro TDD by Example:

1. Escreva um pequeno teste que falhe, e talvez até mesmo sequer compile inicialmente;
2. Faça o teste passar da maneira rápida, cometendo qualquer “pecado” durante este processo;
3. Refatore: elimine toda duplicação criada para fazer os testes passarem.

Desta forma, não é preciso pensar na solução completa (sequer numa classe inteira) antes de começar, basta pensar em um teste apenas e fazê-lo passar. Com o conhecimento adquirido é possível então passar para o próximo teste com mais segurança, e assim avançar até que a solução esteja completa.

Outra noção comum é pensar que TDD trata apenas de testes de unidade. Como bem disse o José no seu post, TDD faz bastante uso de testes unitários. Porém, embora a maioria dos exemplos (inclusive o meu) mostra TDD sendo feito através deste tipo de teste, isto não significa que a técnica está restrita a eles. Escrever testes de aceitação simples antes do código existir também pode colaborar na hora de desenvolver com TDD, já que com eles também pode-se obter feedback sobre a solução.

Embora sejam bem pontuais, observar estes detalhes pode ajudar no uso mais eficiente de TDD. E no geral achei o post do José Olivera bastante útil pra quem está começando 🙂

Apropósito, fiquei contente em ver que mais gente se interessa em escrever sobre TDD. É sinal que a técnica esta se tornando popular. Além disso, recomendo visitas regulares ao blog do José Oliveira. (quem sabe um dia eu ainda respondo o questionário que ele publicou por lá…)