Você sendo um profissional envolvido com desenvolvimento de sistemas já se perguntou o porquê no qual você foi contratado para desenvolver um software? Resumindo uma resposta rápida, seria basicamente para ajudar as pessoas a realizarem melhor, mais rápido e com menos erros suas tarefas diárias repetitivas.

O que me deixa abismado é ver que a maioria dos desenvolvedores tem pleno conhecimento disso, mas mesmo assim se tornam absurdamente resistentes a entender e aderir ao TDD. Seria isso falta de empirismo? Acho muito engraçado ver a quantidade de profissionais perdendo seu tempo em testar manualmente suas soluções e não enxergar que isso é um esforço tedioso, chato e repetitivo. “Casa de ferreiro, espeto de pau” é o que melhor explica gastar tanto tempo criando soluções tecnológicas para resolver problemas dos outros e não parar para pensar que podem escrever programas para resolver os seus.

A velha desculpa da falta de empirismo sobre o assunto de TDD é produtividade. Mas o que é produtividade? Se produtividade for medida através de linhas de código de produção escritas por dia, não tenha dúvidas que escrever testes deixa o desenvolvedor menos produtivo, sim. Entretanto, a real produtividade é na verdade medida na quantidade de linhas de código de produção “sem defeitos” escritos por dia e, nessa perspectiva, o desenvolvedor será muito mais produtivo usando TDD.

Alem disso, se você analisar o dia a dia de um desenvolvedor que faz testes manuais, você pode perceber a quantidade de tempo que ele gasta com os testes. Geralmente o desenvolvedor faz vários ciclos repetitivos de testes enquanto desenvolve um código complexo. Agora pare e pense comigo:

• Quantas vezes o desenvolvedor que esta criando uma parte nova na solução executa o mesmo teste manual?
• Quantas vezes mais outros desenvolvedores precisaram num futuro próximo repetir as mesmas baterias de testes quando precisar alterar um pedacinho de código de um modulo já em produção?
• E se depois de alguns anos de produção, o arquiteto responsável decidir trocar o provider de JPA adotado?

Pode escolher alguém do time de desenvolvimento, colocar o “nariz do bozo” nele e fazê-lo retestar tudinho novamente.

Um desenvolvedor que usa TDD gasta seu tempo em teste apenas uma única vez! Nas próximas ele simplesmente aperta um botão e vê um programa executando o teste para ele de forma correta, rápida e exata. Os testes de um produto em desenvolvimento vão sendo acumulados e agrupados de forma que no fim a solução inteira é testada com apenas um clique. O único caminho para conseguir testar uma solução de maneira continua e sustentável é automatizando os testes. Qualquer profissional hoje dentro da realidade do mercado sabe que não há desculpa para não testar.

É sobre isso que este livro trata. O autor Mauricio Aniche conseguiu compilar esse material incrível, com uma ótima didática relacionada às justificativas, praticas e princípios envolvidos na adesão de TDD. Leitura indicada para todos aqueles iniciantes se acham que estão “perdendo tempo” ao usar TDD.

Boa leitura para todos !