Senhores,
primeiramente eu acredito e utilizo testes unitários, porém, lendo estes artigos, acho que os iniciantes em java poderão cair no erro de programação por testes unitários ou programação para testes unitários.
Essa lógica, me faz lembrar dos irmãos Wright, em que desenvolviam os protótipos e depois, no jargão aqui do sul, soltavam penhasco abaixo e eperavam para ver se voava…
No fundo, essa prática, induz que ao se desenvolver códigos não se precisa de planejamento, de lógica e muito mesnos de experiência. Afinal simplesmentes, se o que você escrever passar nos testes, então seu código será bom…
Eu tive que fazer uma auditoria em um sistema recentemente, em que existia testes unitários para todos os POJOS da aplicação e para uma boa parte das classes de negócio… resumindo: testes mecanicos, sem valor algum, a ponto de encontrar em pojos, coisas do gênero:
public void metodo(String s) {
if( s == null ) {
throw new UnsupportedOperationException("Not supported yet.");
}
// ...
}
Enquanto que nas classes que deveriam representar estados e implementar uma máquina de estado, sequer validava a transição de um estado para outro…
Outra prática que tenho visto em Curitiba, e a delegação da escrita dos testes para estagiários… com um detalhe importante, os mesmos estão construindo estes testes sem conhecimento das regras de negócios, sem o apoio mínimo de uma documentação… estão apenas escrevendo testes para apresentar ao contratante.
Logo, senhores, testes unitários não deveriam ter o valor que estão querendo dar, fazem parte do ciclo de vida de desenvolvimento de software, especificamente para a fase de testes e deveriam estar sendo menos cobrados na fase de desenvolvimento, ou sequer ser confundidade como parte do desenvolvimento.
A relevância dos testes unitários são proporcionais aos conhecimentos e experiência da equipe de desenvolvimento com relação ao ambiente, aos recursos disponíveis e do grau de definição das regras de negócios.
Em uma equipe experiente, com um escopo bem definido e uma boa documentação, eu rediziria a necessidade dos testes para faixas entre 3 e 5% do projeto, enquanto que no inverso, ou seja, em equipe pouco experiente e com regras de negócios pouco claras, eu recomendaria de 75 a 90% dos artefatos produzidos. (Os % são em relação a cobertura das unidades desenvolvidas)
fw
