Ansiedade X Testes

Dando sequência ao post anterior sobre ansiedade, falaremos sobre testes escritos, ou melhor, sobre a ausência deles.

Na pressa por assegurar que um código recém escrito esteja funcionando, o desenvolvedor opta pela forma mais rápida de testá-lo. Em java, uma das vias mais fáceis, é através da escrita do método main() na própria classe em questão. Geralmente o primeiro caso de teste é o tão conhecido “happy path”. Em questão de minutos, a lógica foi escrita, o programa executado, correções executadas e pronto. Pronto? Se houvesse somente um fluxo e nada mais, tudo bem.

Considerando que a pessoa lembrou que existem outros cenários, o que é feito geralmente? Ela edita o código, muda os valores (em vez de criar um novo teste) e repete o processo até obter sucesso. Feito. Dois casos testados e assegurados.

Esse processo ocorre mais algumas vezes e no final das contas têm-se apenas um teste escrito. Caso esses testes fossem estruturados através de um framework, como o JUnit por exemplo, todos os fluxos alternativos permaneceriam escritos.

A grande vantagem dessa abordagem é sobre a manutenibilidade e qualidade do código gerado já que outros desenvolvedores fututuramente irão deparar-se com a sua manutenção. Dessa forma, testes de regressão poderão ser executados facilmente a fim de garantir que a aplicação ainda funciona (em alguns casos, os próprios testes deverão ser ajustados).

De quebra, com a adoção de um framework para escrita de testes, existe a integração com ferramentas que realizam a build do projeto (ant ou maven). Qual a vantagem? Dependendo da configuração, você obriga que o projeto será empacotado se e somente se todos os testes rodem com sucesso.

Concluindo, a ansiedade na etapa de escrita de testes muitas vezes leva o programador a pensar que é perda de tempo estruturar os testes já que num primeiro momento gasta-se mais tempo; o ganho dessa automação geralmente não surti resultados instantâneos, mas quando começa a produzir efeitos, com certeza haverá um alto grau de confiança na alteração de uma lógica, alta rapidez na adequação da aplicação às regras de negócio e resumindo, um alto grau de qualidade.

Até a próxima.

Ansiedade

Ansiedade. Esta aí um dos grandes males que acometem uma grande massa de desenvolvedores de software. Aquela vontade incontrolada de ver as coisas rodando, não importando de qual jeito, mas desde que esteja lá: “funcionando”!

Se essa ânsia fosse acompanhada de esmero na execução do trabalho ela seria benigna. Infelizmente é o contrário que ocorre. Testes são deixados de lado, regras de negócios são entendidas parcialmente, fluxos alternativos são esquecidos, a documentação inexiste ou é escassa/confusa. No final das contas o trabalho deixa a desejar.

“Nós não temos tempo pra isso! O gerente pediu pra ontem!”. Isso é bastante comum, mas não é sempre. Estamos tratando do caso em que existe tempo disponível, mas o imediatismo pelo resultado acaba seduzindo o profissional.

A contrapartida é que esse ganho de tempo é efêmero. No próximo post veremos algumas das consequências.