Eu achei que devessemos praticar sempre o TDD, para facilitar a integracao continua e corrigir possiveis quebras de código .
Eu achei que devessemos praticar sempre o TDD, para facilitar a integracao continua e corrigir possiveis quebras de código .
Olá, Aurelio.
Acho que precisamos do máximo possível de testes, mas nem sempre de TDD.
Às vezes, estamos explorando uma biblioteca ou API, fazendo uma prova de conceito. É boa parte do trabalho de um desenvolvedor. Sempre estamos trabalhando em território desconhecido, não é mesmo?
O próprio eXtreme Programming tem uma prática chamada Spike: um pequeno experimento, uma investigação técnica sobre algum problema.
Um caso interessante é quando precisamos criar algoritmos bem complexos. Será que você consegue criar um bom algoritmo usando TDD?
Em 2007, o Ron Jeffries, um dos pioneiros do XP e TDD, tentou criar um resolvedor de Sudoku (aquele quebra cabeças que vem nos jornais) usando TDD. Pelejou, tentou, insistiu, batalhou e acabou chegando numa solução bem meia-boca.
Então, Peter Norvig, especialista em Inteligência Artificial, diretor de pesquisas da Google e profundo conhecedor de algoritmos, usou uma técnica chamada Constraint Programming e, em poucas linhas, resolveu o problema de maneira muito eficiente.
A questão é que TDD ajudou Ron Jeffries a chegar numa solução mas talvez não a melhor. E não de maneira fácil.
Referência: https://www.infoq.com/news/2007/05/tdd-sudoku