Test-Driven Development – Teste e Design no Mundo Real

Postado em Atualizado em

TDD-280_largeVocê 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ápidas 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 faze-lo retestar tudinho novamente…. kkkkkk :mrgreen: .

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 🙂 !

“O SENHOR firma os passos do homem bom e no seu caminho se compraz; se cair, não ficará prostrado, porque o SENHOR o segura pela mão.” Salmos 37:23-24

Anúncios