Já enumerei as principais razões para utilização da metodologia de Desenvolvimento Orientado a Testes neste artigo (link) e também como praticar em sessões de Coding Dojo neste outro artigo (link), dessa vez quero abortar as leis do TDD (Test Driven Development), essas leis que podemos entender como regras são fáceis de entender e principalmente nos fornecem uma forma simples de validar o que estamos fazendo.
Essas regras foram definidas por Robert C. Martin (Tio Bob), principalmente no intuito de auxiliar no processo de iniciação na utilização da metodologia TDD, essas três regras são mecânicas, você deverá aplicá-las porque irá lhe forçar a escrever código de melhor qualidade e aumentará a facilidade de manutenibilidade.
Lei 1: Você não pode escrever nenhum código fonte, antes de escrever uma especificação de teste que falhe
Isso quer dizer basicamente, o principal e o óbvio para a metodologia, nenhum código pode ser criado, ou classes, ou interfaces, ou seja nada, antes que a especificação do testes seja escrita e falhe, que obviamente irá falhar porque não tem nenhum código para ser validado.
Lei 2: Você não pode escrever mais do que um teste para falhar (e não compilar é falhar)
Muitas vezes já queremos adiantar todas as possíveis soluções e cenários plausíveis para garantir que o que iremos desenvolver irá cobrir os testes e atendendo os resultados esperados, porém esses testes não são testes unitários, são especificação de testes de comportamento, ou seja, você terá que primeiro escrever uma especificação de teste, essa especificação falhará, você então irá codificar para passar no teste e só depois você poderá escrever uma nova especificação de teste para um novo comportamento, dessa forma a cada nova especificação, codificação, estará sendo criado uma pilha de testes que continuaram sendo validados sobre o que está sendo desenvolvimento com qualidade e sem quebras.
Lei 3: Você não pode escrever código fonte mais do que o suficiente para passar no teste que está falhando
Essa talvez seja a regra mais difícil de executar, porque como programador é natural durante o processo de implementação, já tentamos adiantar passos e prever condicionais, situações e comportamentos, porque dessa forma conseguimos escrever códigos que aceleram a implementação final, porém a metodologia nos obriga a dar um passo de cada vez para que possamos ter ciência e principalmente cobertura de todo o processo, com isso fica bem claro que o código fonte que devemos implementar tem que ter o propósito de fazer o teste ser passado e somente isso. Um exemplo básico para ilustrar, caso escreva um teste que precise validar a soma de dois valores (exemplo 1 e 3), sua função deve simplesmente retornar 4, isso fará o teste passar. O motivo por trás disso é forçar você a pensar e dar pequenos passos e ser muito mais produtivo do que tentar codificar em grandes etapas.
Essas três leis podem parecer simples e talvez irão criar um processo moroso inicialmente, entretanto a principal função do TDD é garantir qualidade de código gerado e principalmente cobertura de testes focadas na solução do problema. Ter implementações menores oferecem um poder de concentração maior num único ponto, o que potencializa sua capacidade de resolver o centro do atual problema, com o ponto resolvido, você passa para o próximo e assim até o final. É exatamente para isso que servem essas três leis.
Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil