Fiquei muito satisfeito em ler em um texto recente do DHH que ele está, na verdade, utilizando TDD***. Fico satisfeito de ver que ele percebeu que o TDD não está, de fato, morto.

Este artigo é uma simples resposta, somente para apontar algumas coisas com as quais não concordo. Mas tenho que admitir: concordo mais que discordo.

DHH apresenta sete pontos, que reproduzi abaixo, junto com meus comentários. E desde que o DHH não justificou suas opiniões, não vou justificar as minhas.

1) Não mire uma cobertura de 100%.

Discordo. Mire o mais alto que puder. Trate 100% como um objetivo assintótico. Nenhum outro número é um objetivo razoável. Nunca há razão para parar de aumentar sua cobertura.

2) Proporção de código testado acima de 1:2 é um cheiro, acima de 1:3 é um fedor.

Discordo. 1:1 é o certo. Se você tem 20k linhas de código, provavelmente deveria ter 20k linhas de teste (a propósito, não consigo entender as proporções do DHH. Eu acho que ele quis dizer a primeira ao contrário (2:1) e a segunda como (1,5:1). Ou talvez estou sendo somente obtuso.

3) Você provavelmente está fazendo errado se os testes gastam mais que 1/3 do seu tempo. Você está definitivamente fazendo errado se está gastando mais que metade do tempo.

Concordo. Testar não deveria gastar nada do seu tempo. Escrever os testes, com TDD, requer um tempo negativo (por exemplo: economiza um tempo). Todos os testes que valem a pena e você não escreve custam tempo.

4) Não teste associações active records, validações ou escopos.

Concordo. Normalmente não existe razão para testar seu framework, caso você confie nele. Se você não confia nele (e existem muitos frameworks por aí que não são confiáveis), então escrever alguns testes para o framework pode valer a pena. Considere isso equivalente à uma “Inspeção de Recebimento”.

5) Reserve testes de integração para os problemas que surgem da integração de elementos separados (isso também é conhecido como: não faça testes de integração em coisas que podem ter testes unitários).

Concordo. Mantenha o foco dos seus testes. Não teste UIs. Não teste servidores web. Teste o máximo do código que você puder.

6) Não utilize o Cucumber, a menos que você viva no reino mágico dos Não Programadores Escrevendo Testes (e me envie uma garrafa de pó mágico se estiver lá!).

Concordo e discordo. Cucumber (Gherkin) vale a pena apenas se você tem o pessoal de negócios ou do controle de qualidade que queiram ler seus testes. Se eles também escrevem testes de aceitação então: ABSOLUTAMENTE envie o pó mágico de lá, porque vale seu peso em diamantes.

7) Não se force a primeiro testar cada model, view e controller (minha proporção é de 20% de testes anteriores e 80% de testes posteriores).

Concordo. Mais ou menos. Alguns controllers, models e views são muito estúpidos para se preocuparem com testes. Se estão obviamente corretos, porque são uma linha de código, então testá-los pode ser supérfluo. Mas tenha cuidado. Às vezes, uma linha de código tem 20 linhas de semântica.

*** Foi mostrado para mim que o post do “TSA” na verdade, antecedeu o post “TDD está morto” por vários anos. De alguma maneira, eu os li na ordem invertida.

***

Uncle Bob faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://blog.cleancoder.com/uncle-bob/2017/03/06/TestingLikeTheTSA.html.