Eu tenho uma anedota relevante de algo que está acontecendo agora para mim. Estou em um projeto que não usa TDD. Nosso pessoal de controle de qualidade está nos movendo nessa direção, mas somos um grupo pequeno e esse processo foi longo e prolongado.
De qualquer forma , recentemente eu estava usando uma biblioteca de terceiros para executar uma tarefa específica. Havia um problema em relação ao uso dessa biblioteca, por isso me foi pedido escrever essencialmente uma versão dessa mesma biblioteca. No total, acabaram sendo cerca de 5.000 linhas de código executável e cerca de 2 meses do meu tempo. Eu sei que linhas de código é uma métrica ruim, mas para essa resposta, sinto que é um indicador decente de magnitude.
Precisava de uma estrutura de dados específica que me permitisse acompanhar um número arbitrário de bits. Como o projeto é em Java, eu escolhi o Java BitSet
e o modifiquei um pouco (eu também precisava rastrear os principais 0
s, o que o BitSet do Java não faz por algum motivo .....). Depois de atingir ~ 93% de cobertura, comecei a escrever alguns testes que realmente enfatizariam o sistema que eu havia escrito. Eu precisava avaliar determinados aspectos da funcionalidade para garantir que fossem rápidos o suficiente para os meus requisitos finais. Sem surpresa, uma das funções que eu havia substituído na BitSet
interface era absurdamente lenta ao lidar com grandes conjuntos de bits (centenas de milhões de bits nesse caso). Outras funções substituídas dependiam dessa única função, por isso era um gargalo enorme .
O que acabei fazendo foi ir à prancheta e descobrir uma maneira de manipular a estrutura subjacente de BitSet
, que é a long[]
. Projetei o algoritmo, pedi a entrada de colegas e depois comecei a escrever o código. Então, eu fiz os testes de unidade. Alguns deles quebraram e os que me apontaram exatamente para onde eu precisava procurar no meu algoritmo para corrigi-lo. Depois de corrigir todos os erros dos testes de unidade, pude dizer que a função funciona como deveria. No mínimo, eu poderia ter tanta certeza de que esse novo algoritmo funcionou como o algoritmo anterior.
Claro, isso não é à prova de balas. Se houver um erro no meu código que os testes de unidade não estejam verificando, não saberei. Mas é claro que esse mesmo bug poderia estar no meu algoritmo mais lento também. No entanto , posso dizer com um alto grau de confiança que não preciso me preocupar com a saída errada dessa função específica. Testes de unidade pré-existentes me pouparam horas, talvez dias, de tentar testar o novo algoritmo para garantir que ele estivesse correto.
Esse é o ponto de realizar testes de unidade independentemente do TDD - ou seja, os testes de unidade farão isso para você no TDD e fora do TDD da mesma forma, quando você refatorar / manter o código. Obviamente, isso deve ser associado a testes de regressão regulares, testes de fumaça, testes difusos, etc., mas o teste de unidade , como o nome indica, testa as coisas no menor nível atômico possível, o que fornece instruções sobre onde os erros apareceram.
No meu caso, sem os testes de unidade existentes, eu precisaria, de alguma forma, criar um método para garantir que o algoritmo funcionasse o tempo todo. Que, no final ... parece muito com teste de unidade , não é?