É comum as pessoas assistirem palestras/workshops/evangelizações/s.a. sobre test-driven development (TDD) e ficarem empolgadas para começar a escrever testes automatizados nos softwares que desenvolvem, mas quando começam a desenvolver, sentem-se perdidas e improdutivas, daí desistem. Testar primeiro é uma cultura, e ninguém muda de cultura só por que ficou empolgado com uma apresentação sobre uma cultura diferente. Passada a empolgação, entendendo os benefícios do TDD, acreditando no TDD e desejando realmente praticar TDD, um desenvolvedor ainda vai ser “pouco produtivo” com TDD.

Digamos que um desenvolvedor precise de um tempo x para implementar entregar uma funcionalidade de um sistema, é óbvio que ele vai gastar um tempo maior que x para entregar esta funcionalidade com TDD, por que ele não escreve só a funcionalidade, escreve também os testes que garantem o funcionamento da mesma. Pensando dessa forma, é óbvio que qualquer desenvolvedor, ainda que seja um TDD Jedi Certified Developer, será menos produtivo fazendo TDD. Assumindo que produtividade é a relação entre codificação e tempo, fazer TDD significa perder produtividade, e aqui começam os problemas culturais…

Um desenvolvedor rápido, com a incrível capacidade de produzir 5 linhas de código por segundo, realmente é um desenvolvedor mais produtivo? Programar é só digitar? Quanto mais código você cospe em um programa, mais produtivo você é? Se eu escrever muito código em pouco tempo serei produtivo ainda que o código escrito não funcione ou seja lixo? Quando você entrega a funcionalidade para o cliente, qual garantia ele tem que tal funcionalidade realmente funciona?

Mensurar produtividade fazendo TDD significa levar em consideração que produtividade é a relação entre a quantidade de funcionalidades implementadas e o tempo que elas levam para serem implementadas, entendendo que a definição de “implementar a funcionalidade x” é construir um software capaz de atender a uma necessidade ou a um desejo do seu cliente, e certamente é um desejo/necessidade do seu cliente que todas as funcionalidades implementadas funcionem. Não estou defendendo que softwares escritos com TDD não possuem bugs, mas que os bugs em softwares escritos com TDD aparecem com menor frequência e, quando aparecem, são detectados com maior facilidade.

Entregar uma funcionalidade testada e funcionando significa que caso ela não seja aprovada pelo cliente, o motivo provavelmente não será por que o seu cliente viu uma exception na tela quando ele clicou naquele botão que você estava torcendo para ele não clicar ou um erro maluco da sua aplicação. Sua funcionalidade não ficará imune à desaprovação do seu cliente: seu cliente poderá dizer “não era isso que eu queria”, problemas de comunicação estão fora do escopo do TDD, mas certamente seu cliente não vai ficar decepcionado por investir tempo em uma apresentação de um software ou uma funcionalidade que simplesmente não funciona.

Portanto, não pense ser estranho o fato de você se considerar menos produtivo fazendo TDD. Na cultura tradicional de desenvolvimento de software, todas as pessoas são pouco produtivas quando fazem TDD. O conceito de produtividade em TDD é outro, e neste contexto, quando você não faz TDD, é impossível sequer ser produtivo, pois se você não pode garantir o funcionamento correto de uma funcionalidade, não existe nenhuma garantia que você não está gastando seu tempo produzindo código morto.