Já leu isto? https://dhh.dk/2014/tdd-is-dead-long-live-testing.html.
Não é qualquer um falando. É um dos que mais defenderam o uso. E ele admite que foi como religião. Como acontece com muita coisa em toda a sociedade hoje em dia. E tem muito em tecnologia. A pessoa adota porque as outras estão falando que é bom, e aí qualquer um que falar contra é um herege. Isso não é saudável, para qualquer coisa. Algumas pessoas que são consideradas muito boas na nossa área tentaram e não viram vantagem. Complemento de leitura.
Muitas pessoas adotam TDD sem saber bem se ele é tudo o que falam. Isso é normal, é o jeito de saber mais sobre ele. O problema é que se não for tão bom, mas der algum resultado, mesmo que traga junto alguns malefícios, a pessoa se dá por satisfeita e não consegue se livrar se for o mais adequado.
Obviamente muita gente usa e deve achar que tem benefícios. Muita gente não usa porque não consegue ver os tais benefícios. Talvez seja porque eles não existem. Pelo menos em certos cenários. Ou tem a pessoa também viu malefícios, que mesmo tendo benefícios tem efeitos colaterais, que para alguns pode ser ruim. Para outros pode ser aceitável.
Eu sou dos que nunca vi tanto benefício e vi malefício. Fazer teste é bom, fazer TDD não é. Até porque TDD nem é sobre testes, de verdade, e muita gente já usa errado por isso. O teste é usado como ferramenta e não o fim. A função do TDD não é testar software, é documentar o'que deve ser feito.
Pra mim é feito de tal forma que, ou dá muito trabalho ou engessa o desenvolvimento e inibe a criatividade. Frequentemente vejo projetos que usam TDD muito inferiores ao que poderiam ser. E muitas vezes anda mais lento do que deveria. Algumas pessoas até mais especializadas nisso do que eu, e defensores do TDD, não recomendam em lugares que exigem inovação, e que é preferível em locais mais burocráticos. Nem todo mundo concorda com isso. E onde tem muita discordância algo tem de errado.
TDD pode e tenho visto acontecer de criar danos para o projeto, que é o que importa.
Inclusive é complicado porque ele é meio que tudo ou nada. Não adianta selecionar o que fará TDD e o que não fará, porque isso diminui muito o valor. Testes sem metodologia tão restritiva podem ser usados conforme a necessidade e benefícios que cada parte pode ter.
E nem vou levantar a bandeira de quem muita gente já não faz testes bem, imagina testar o que nem está feito ainda. Eu admito que um dos motivos que eu não faço é ter dificuldade em testar bem. Claro que sei escrever testes, mas testar errado é mais fácil do que muita gente vê. E os testes acabam sendo feitos burocraticamente, não para aumentar o valor do projeto. É fácil achar que está testando bem, mas eu vejo muitos testes ruins em códigos mais low profile que vejo por aí. Não são péssimos, mas testes o'que não precisa, deixam de testar muita coisa que é necessária. Em TDD essas falhas importam mais.
E muitas vezes há até corrupção, porque para conseguir atender os objetivos a pessoa pode desvirtuar o teste ou até o código principal, que sempre deve ser o mais importante.
O teste ajuda a ter mais confiança no código, o TDD não diretamente. Claro que ele pode fazer isso, mas não é o objetivo principal, e mesmo pegando essa melhoria que acontece, é por causa do teste e não porque fez TDD.
Eu falei mais em https://pt.stackoverflow.com/q/199885/101.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).