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.