O problema começa no modo como as pessoas projetam o software, dentro de um processo Waterfall, onde cliente não é parte do processo. Neste contexto, o cliente diz o que deseja e depois de 9 meses ele tem um resultado: um software produzido nas “coxas”.

Mesmo em projetos onde existem práticas de testes, muitos deles ainda são ineficientes. O usuário apenas valida as “telinhas” do sistema, e muito pouco em termos funcionalidades. Infelizmente, poucos destes usuários testam o comportamento de entradas de dados inválidos, por exemplo, um campo de CPF aceitar “-1″ como valor, ou um espaço em branco ser um conteúdo válido para um campo obrigatório. Como resultado, o sistema chega a produção, dados inconsistentes são inseridos e a culpa é do desenvolvedor.

Testes unitários é algo que muitos desenvolvedores ainda acham inútil, quando fala em integração contínua, aí acham exagero. Quer um exemplo, pergunte à um programador PHP se ele faz teste unitários. “Faço apenas sites, não sistemas, não preciso disso”, nem fazem idéia de que existe o PHPUnit para este propósito. Mesmo dentro de um obsoleto modelo cascata, cheio de casos de usos, porque não criar testes unitários pelo menos para validar os fluxos principais e alternativos? Pelo menos o fundamental pode ser controlado por um sistema de integração contínua.

Meu objetivo não é falar que práticas, como TDD, são perfeitas. O que eu quero chamar a atenção é importância que o teste tem dentro de um processo de desenvolvimento de software. Aparentemente, gastar algum tempo a mais fazendo testes, pode ser mais eficaz do que ter que corrigir uma falha que foi para produção por pura falta de atenção. Testar não é fácil e rápido, porém corrigir bugs pode ser mais demorado ainda.