Eu achei que devessemos praticar sempre o TDD, para facilitar a integracao continua e corrigir possiveis quebras de código .
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
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