Cedric Beust e Alexandru Popescu, criadores do framework de testes TestNG, fizeram uma apresentação entitulada “Designing for testability“.
Eles falaram algumas coisas interessantes sobre os “inimigos” da testabilidade como chamadas entranhadas à métodos estáticos, encapsulamento ao extremo (atributos private final) e cuidado com Singletons.
No geral a apresentação foi média mas acabou servindo para levantar um ponto importante.
Num determinado momento eles falaram claramente que não acreditam muito em Test-Driven Development porque ninguém nunca vai aplicar corretamente. Eles alegam que as pessoas não gostam de escrever código que dá erro de compilação e que fica “vermelho no Eclipse” para depois escrever código que funciona. Por isso eles na maioria das vezes não usam a técnica.
Eu acho que isso não é um problema do TDD mas um problema das IDEs! O que acontece é que com essas IDEs semi-automáticas de hoje em dia as pessoas ficaram muito acostumadas com o Ctrl+Enter e escrever o teste antes implica em não ter esse tipo de funcionalidade, o que pode dar uma falsa impressão de que você está fazendo algo estúpido. Sem contar que a feature “Build Automatically” faz com que o seu código fique assustadoramente vermelho quando a IDE tenta compilar o teste e não consegue… Se você programar em Ruby, por exemplo, essa falsa impressão desaparece. Quando você escrever um teste para um código que não existe, simplesmente o teste não vai funcionar. Nada de alarmes vermelhos na IDE. Enfim, para mim é uma questão de hábito. Coincidentemente numa das palestras seguintes o Charles Nutter falou exatamente sobre isso e concorda que o problema do TDD no Java são as IDEs.
Para finalizar sobre esse papo de TDD ou não-TDD, gosto muito daquele provérbio budista que diz: “vá sempre pelo caminho do meio“. Não acredito que todo mundo deva ser pragmático e sempre escrever todo e qualquer teste antes de programar absolutamente qualquer coisa. Ninguém vai morrer se você escrever testes junto com a implementação em certos casos. Para mim o que mais importa nisso tudo é o mindset de possibilitar que as dependências sejam isoladas, ter uma suite de testes decente para garantir qualidade/permitir refactorings seguros e coisas desse tipo.