Não me entenda mal, este não é mais um artigo do tipo “você deve praticar TDD porque…”. Meu objetivo é atingir aqueles que desejam iniciar nisso, mas precisam de um guia sobre como tirar o máximo benefício dele e evitar desastres típicos. Diferentes tipos de testes (e práticas de testes) fornecem benefícios diferentes, e eu pensei que talvez eu pudesse escrever algo a que você possa se referir de tempos em tempos. Portanto, estas são as virtudes prometidas, em ordem cronológica.

01. Testes te ajudam a criar o design da API da sua classe

Você pode ter ideias elaboradas sobre seus métodos e propriedades, mas os usuários que de fato usam suas coisas pensam diferente. Seja o primeiro usuário da sua classe antes de escrevê-la, e você a deixará pronta e correta antes que qualquer pessoa a veja.

02. Testes te ajudam a criar o design da arquitetura do seu sistema

Você acha que é inteligente. Aqueles diagramas DML deixam sua mãe orgulhosa de você. Até você voltar para o seu app depois de um ou dois anos e ter que fazer algumas mudanças. Você descobre alguns métodos LOC 2000, statements goto, e até procedimentos armazenados. Meu Deus, que bagunça!

Não existe prova rigorosa, mas várias fontes nos dizem que designs direcionados para testes são muito mais flexíveis e sustentáveis. Existem muitos motivos para acreditarmos nisso, o que vale até um artigo separado.

De qualquer maneira, se você parar de fingir que é a prova de falhas, e começar a escutar os seus testes, você poderá melhorar o seu design além dos seus sonhos mais improváveis. Isso é considerado o maior benefício do TDD, apesar de não ser óbvio desde o início, pois isso não está diretamente relacionado a testes.

03. Testes te ajudam a implementar os membros da sua classe

Direcionado a testes, seu método eventualmente se torna a coisa mais simples do mundo que funciona. A maior parte do que dissemos acima se aplica ao design no nível de membros também.

04. Com testes, você tem certeza de que sua aplicação ainda vai funcionar corretamente depois que você mudá-la

Depois de fazer uma pequena mudança à implementação subjacente de um certo recurso menor, você testa manualmente todo o sistema… ou seus usuários finais fazem isso por você. De qualquer maneira, você passa o fim de semana tentando entender os dados corrompidos de um back up que você fez acidentalmente alguns dias atrás (não estou inventando isso, realmente aconteceu comigo!).

Testes, quando feitos apropriadamente, podem ser uma rede de proteção que te protege de acidentes infelizes. Você pode refatorar seu código livremente com o objetivo de melhorar o seu design, sem ter medo de introduzir um bug de regressão.

05. Testes documentam a sua API

Ao estruturar seus testes em volta de classes (o que não é a melhor ideia, mas é ok para começar), você pode olhar para um teste em particular e compreender o que o método correspondente faz. Isso é, se o teste estiver nomeado e escrito devidamente.

06. Testes documentam o seu sistema

Isso não quer dizer a mesma coisa que o falado no tópico anterior. Ao olhar para um sistema novo, estou tentando entender como fazer as coisas com ele, não o que uma classe em específico faz. Portanto, ao estruturar os seus testes em volta de recursos do sistema, você fornece uma boa maneira para documentar seu comportamento, “como usar o recurso x” e “o que acontece se eu de fato usá-lo”.

Já deram sete?

Se você souber de outros benefícios, por favor, escreva-os nos comentários!

Ok, e agora?

Espero que você não use o TDD só porque te falaram para usar, mas porque você quer tirar vantagens dele. Agora que você conhece esses benefícios, você não os usa cegamente. Você tenta escrever seus testes de modo que eles deixem a refatoração mais fácil, não difícil. De modo que eles de fato influenciem seu design, e não o contrário. De modo que eles sejam fáceis de entender, e façam com que você compreenda o sistema mesmo se for um completo estranho.

Como você consegue isso? Ah, isso é outra história.

***

Texto original disponível em http://ivonna.biz/blog/2011/6/10/seven-virtues-of-test-driven-development.aspx