Você escreve testes que agregam valor ao produto ou apenas escreve testes?

Baby steps, test-first, good enough code, red-green-refactor cycle, etc. Test-driven development (TDD) parte de vários princípios e práticas para construção de código de qualidade, com “garantia anti-bugs”. Com essa garantia, evangelistas apresentam o TDD como solução de qualidade para o produto que você constrói.

Recentemente, me peguei num momento de fanatismo por TDD e rodei um coverage num projeto que eu estava construindo, percebi que eu tinha 51% de cobertura de testes e resolvi que eu teria 100% de cobertura, e para isso eu fui praticar o amado TLD e assumir o compromisso de, daqui pra frente, fazer TDD para manter a cobertura em 100%.

Após uns 20 minutos de refactoring e escrita de testes (o projeto é novo, ainda está pequeno), eu tinha 95% de cobertura. Estava quase lá, faltavam apenas algumas poucas linhas de código que faziam chamadas a alguns frameworks e bibliotecas não construídos por mim, não era necessário testar essas linhas, mas eu queria a medalha de 100% de cobertura.

Passaram-se 45 minutos e depois de tentar seis ou sete frameworks de mock diferentes, eu ainda tinha 95% de cobertura e estava com problemas para testar aquelas linhas que não precisavam ser testadas. Era 4 da matina, achei melhor dormir, no dia seguinte eu estaria com a cabeça mais tranquila e resolveria num piscar de olhos.

No dia seguinte, lá vou eu tentar a cobertura de 100%, mais 30 minutos e problema resolvido, eu tinha 100% de cobertura de testes. Foi satisfatório? Sem sombra de dúvidas. Agregou valor ao produto? Não. Eu estava me preocupando em escrever código de qualidade para fazer TDD, e não o contrário. TDD é um meio, não o fim.

Se, pra você, ter 100% de cobertura de testes é apenas uma relação estatística entre testes e linhas de código do seu projeto e não agrega valor ao produto, não tenha 100% de cobertura. Não existe código grátis, e isso inclui seus testes.

Uma das premissas do TDD é escrever código suficiente para passar nos testes, assim você se livra do lixo no seu código. E quanto ao lixo nos seus testes, você vai fazer TDD recursivo? No artigo Disputa TDD: Mozart x Bethoven, Fabrício Vargas mostra que não é pecado escrever sua função inteira sem que você tenha mais de um cenário de testes. Você pode até escrever a função antes do teste sem se sentir eternamente culpado por isso. Nem sempre os passos de bebê são a resposta, nem sempre TDD é o caminho.

Não quero acabar com os baby steps. Eu sou a favor de caminhar com passos de bebê, desde que você não conheça a solução final. Se um bebê nascer sabendo andar, ele vai ficar deitado, pulando de colo em colo, se arrastando no chão, “andando” de quatro, para então começar a andar sobre suas duas pernas?

TDD é um meio para atingir um objetivo, não o objetivo. Os testes do seu produto não são mais importantes do que o seu produto, não inverta os papéis, não use seu produto para fazer TDD plenamente, use o TDD (plenamente ou não) para ter um produto melhor.