Software profissional tem teste, incondicionalmente

Já se foi o tempo em que um desenvolvedor só programava. E esse tempo não deixou muita saudade. O fato é que é impossível, hoje, desvincular da atividade de desenvolvimento, a etapa de construção dos testes automatizados. Afinal, como eu sei se eu terminei de codificar, que meu objetivo foi atingido? Os teste ajudam a saber isso. E muito mais!

É muito comum adotar a prática conhecida por TDD, brilhantemente descrita pelo ilustre Kent Beck. Segundo essa proposta de abordagem, primeiro é pensado no teste, para depois fazer o código propriamente dito. Não é meu objetivo explicar TDD aqui, pelo menos não nesse post. Recomendo fortemente a técnica. Se não conhece, vá atrás. Agora.

Os testes ajudam a definir o critério de pronto (done), indicando que o código está apto a ser entregue. Além disso, a bateria de testes roda de forma automática, a um custo muito baixo. Isso ajuda a evitar o que é conhecido como regressão do software. Em um cenário em que a cobertura de testes está boa, se há algo funcionando e uma manutenção gera um comportamento inadequado como efeito colateral, pelo menos um teste vai quebrar. Há quem diga que a cobertura de testes é a rede de segurança, para fazer movimentos mais ousados no código, sabendo sempre que será avisado se algo der errado, com a oportunidade de arrumar enquanto é barato fazer isso.

Testes ajudam a documentar o código. Os cenários de testes descritos facilitam o entendimento de um programador novo no contexto. Ou mesmo de um veterano, que há tempos não passa por ali.

Incorporar testes deve ser barato. Se está difícil de testar, bem, pode ser um indício que o seu código está complicado demais. E, por favor, não venha com essa conversa que isso aumenta o custo do software. Quanto custa não ter testes? Quanto custa alterar o código e não saber se quebrou algo? E envolver uma pessoa, ou mesmo uma equipe, para testar novamente, na mão? E se precisar repetir esse teste? Quanto tempo demora? Se colocar isso na ponta do lápis, vai notar que é praticamente rasgar dinheiro não plugar testes no seu código. Bom, dizem que os loucos rasgam dinheiro. Sua loucura está nessa categoria? Espero que não!

Testes podem exercitar várias granularidades. Explico melhor: pode-se testar unidades, que são as partes mais fundamentais do seu código. No mundo java, por exemplo, temos o famoso JUnit. Fortemente recomendado.
Também podemos o comportamento do sistema, em que encontramos objetos interagindo, ou a implementação de um serviço e sua pilha de execução. Para isso temos ferramentas, como o Cucumber, que tem grande fama no mundo Ruby. O mais legal dessa abordagem é que os testes são escritos de forma que um leigo consiga interpretar e, claro, validar. Mais que recomendado o seu uso.
Também podemos simular usuários acessando o sistema, sendo por meio de uma enxurrada de requests em um site (Jmeter é muito bom para isso), ou mesmo imitando o comportamento de um usuário navegando em um browser (Selenium é um clássico).

Certo, o assunto testes, em especial a categoria automatizada, já rendeu vários livros e não dá para esgotar um assunto em um post. Só queria salientar que testar é mais que obrigação do programador. Não só dele, é verdade, mas dá para aumentar e muito a garantia da qualidade quando se programa testes. Se você só faz código de produção e não escreve testes, meu amigo, é melhor sair da caverna e ver que o mundo mudou. E ficou bem melhor.

Provocações finais

Você nunca fez um teste unitário? Hummm... Não acha que está na hora de fazer?
Você só faz testes unitários? Já é alguma coisa, mas você acredita mesmo que se todas as partes funcionarem isoladas, não há risco algum de dar algum problema quando as integramos?
Sua classe está difícil de testar? Você já ouviu falar do livro Working effectively with legacy code?
Como você valida seu site em diversos navegadores diferentes?
E, afinal, quem testa os testes???


Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Requisitos conflitantes e dilemas no projeto de software

Arquitetura em projetos de aplicações em nuvem - noções iniciais