Eu sou um forte defensor de testes automatizados de software. De todo tipo: de unidade, integrados, via interface gráfica, caixa preta, caixa branca, etc. Eu acho que eles ajudam muito. Eu sempre falo isso nos treinamentos de PSD e PSM, além dos outros. E eu sempre defendi: sem testes você não é ágil, na grande maioria dos casos. Sou praticante de TDD e não faço software de outra forma.

Só que uma coisa é testar pra acrescentar valor e habilitar agilidade, habilitar mudanças de forma fácil. Outra coisa é testar cegamente, sem acrescentar valor, sem entender exatamente porque você está testando. É o que chamamos de programação por coincidência: você ouviu falar que era bom, então você testa. Testa sem saber por onde começar, ou o que testar, ou sequer o propósito do teste, ou a meta. Não é a toa que movimentos juvenis como o Programming Motherfucker reclamem que em vez de fazer software funcionar, as pessoas fazem toneladas de testes inuteis. Apesar de o movimento como um todo ser uma reclamação infantil algumas críticas são válidas, como essa.

Testes são ativos de código, e demandam manutenção. Se você fizer errado vai gerar custo em vez de acrescentar valor.

Como isso pode acontecer? Quando você…

• … insiste em fazer um teste de interface gráfica que é muito complexo, leva muito tempo, garante muito pouco no futuro, e ajuda pouco no design
• … escreve um teste difícil de ser lido
• … escreve um teste difícil de ser mantido
• … busca uma cobertura de código mais alta do que o seu software permite
• … não refatora nas oportunidades que o código te dá

A principal medida de progresso é software funcionando. Está no manifesto ágil. E tem gente que acha que testes, que são artefatos e não são o software funcionando, são a principal medida. Deve haver equilibrio, e o foco deve sempre ser fazer a release de forma sustentável. Testes apoiam isso, mas não são o foco.

Como tudo em desenvolvimento de software, testes demandam senioridade, experiência, conhecimento, estudo. Você vai ficando melhor com o tempo, aprende a testar coisas novas, e já não testa algumas outras coisas. Aprende técnicas novas. Faz diferente. É shu-ha-ri. E uma das coisas que eu aprendi é que não temos que testar tudo, e que às vezes menos testes é melhor do que mais testes.

E mesmo TDD, que eu amo e pratico, às vezes eu deixo de lado, e faço uma parte com test later. Ainda que em geral a grande maior parte eu faça com test first.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.