Estamos perdendo a liberdade, criatividade e até mesmo a agilidade.
Antes de mais nada, quero dizer que TDD pode fazer sentido em certos cenários. Não é uma ferramenta que nunca deva ser usada, e não estou pregando que não se deve fazer testes. Tenha sempre isso em mente ao ler o texto.
TDD tende a engessar o desenvolvimento. Ou então ele perde parte de sua eficácia e aumenta bastante o custo, trazendo morosidade. Por isso, o TDD costuma ser usado em ambientes mais burocráticos, que não são muito ágeis, inclusive no sentido da metodologia e de incompetência, porque foi adotado por modinha, e onde os requisitos não costumam mudar muito, não porque traz benefícios.
TDD teve alguma popularidade, na verdade muito pequena; fala-se mais dele do que se usa, pelo mesmo motivo que há tanta gente vendendo consultoria/coaching de Agile. Deturparam o uso da metodologia Ágil, tornando tudo o que ela prega no contrário, e o TDD também. As pessoas adotaram porque outras adotam. É difícil, quase impossível, encontrar quem adotou usando métricas e provando que foi melhor. Ironicamente, TDD funciona melhor usando Waterfall.
E já começa errado porque as pessoas confundem TDD com técnica de teste. Sim, ele faz testes, mas o objetivo é documentar requisitos de forma detalhada. E trabalhar assim tolhe o desenvolvimento e o torna mais burocrático, a não ser, novamente, que use o TDD como um fardo.
TDD é mais uma ferramenta para lidar com a mediocridade. O que tem seu lado bom — isso não é uma crítica. E, se alguém está pensando que estou ofendendo alguém, procure um dicionário. Da mesma forma que OOP é uma ferramenta assim, o que ajuda quase todo mundo que programa, e muito, se usado no contexto certo. OOP ajuda a gerenciar a complexidade. Mas tome o kernel do Linux como exemplo: deve ser a maior base de código do mundo, e é terminantemente proibido chegar perto de OOP (sim, dá para usar em C). Claro que fazem isso porque só programador pica das galáxias põe a mão lá. Também não usam TDD. Microsserviços são outra ferramenta que quase sempre é adotada pelo mesmo motivo. OOP é um pouco mais útil em muitos cenários, mas não TDD (e microsserviços); as pessoas adotam pelo hype.
Outro exemplo que dou é na criação de compiladores das linguagens mais populares. Tem tudo para usar TDD. Afinal, você já tem os requisitos antes, sabe qual a saída que deve obter antes de saber como chegar nela. Procure quantos compiladores populares foram escritos usando TDD. Por que será? Quem trabalha com isso são os melhores programadores do mercado. Por que eles não adotam TDD em uma situação que é tão favorável? Já parou para pensar nisso? Se você não conseguir refletir adequadamente sobre isso, fará TDD tudo errado.
TDD foi criado e divulgado por quem ganha muito dinheiro vendendo consultoria e afins, não é algo orgânico. O problema é que TDD não é tão fácil, e para obter bons resultados a pessoa precisa saber muito o que está fazendo — da mesma forma que OOP. Por isso, tanta gente usa e piora a situação. Força a pessoa a pensar melhor sobre o problema, mas, se ela não pensar, é tragédia. Quando a pessoa sabe muito o que está fazendo, ela evita o TDD.
É verdade que o TDD pode ajudar o medíocre a fazer OOP de forma melhor.
Em vários casos, TDD acaba te induzindo a criar algo complexo demais, ignorando KISS e YAGNI. Obsessão por testes também pode fazer isso. Testar é bom, piorar o core do produto por isso, não. Minha experiência é que você nunca sabe como ocorrerão as mudanças, o que Agile também prega. Se você não sabe, fará um monte de coisa extra para algo que nunca mudará, ou não fará nos pontos que mudarão e você não conseguiu prever, ou criará um código em um nível de complexidade absurdo para fazer o que alguns mandaram você fazer, mas não terão que arcar com os custos disso, nem sequer verão seu código um dia. Eles estão mandando você fazer porque não têm consequências para eles.
O TDD pode ser a forma de você admitir que tem limitações e precisa dele para ajudar. Como exemplo, eu prefiro tipagem estática porque tenho limitações (também por outros motivos que não vêm ao caso aqui). E isso é positivo. Pior é quem acha que consegue tudo e deixa de usar algo por ignorância ou teimosia. O TDD pode te dar confiança, mas pode dar uma confiança ruim. Muitos adotam a técnica sem ter as condições para isso. Não é o TDD que é ruim, é a pessoa que usa que é. Isso precisa ser resolvido de forma ampla. Eu vi muito TDD ser usado para atrapalhar.
Durante décadas, as pessoas não usaram TDD e souberam fazer código coeso e desacoplado. É uma questão de saber programar.
O programador pragmático de verdade usa a ferramenta que melhor lhe atende de forma comprovada. Se ele não consegue comprovar, ele é ideológico. Se realmente obtém melhor resultado com TDD, então deve usar. Se não usar, está perdendo as vantagens citadas no artigo original. Por isso, eu prego que as pessoas devem estudar o TDD e analisar bem quando devem adotá-lo. Se estiverem bem capacitadas para isso, tomarão a decisão certa; caso contrário, só brincarão de "o mestre mandou".
Antes de adotar algo, garanta que conhece muito bem todo o universo à sua volta, seja questionador, tenha certeza de que interpreta tudo corretamente, tem um pensamento científico e especialmente matemático, faça uma avaliação criteriosa, procure informações contrárias e ouça pessoas experientes contraditórias.
Eu nem resvalei nos problemas específicos do TDD; isso farei no meu canal, quando realizar um estudo mais aprofundado antes de publicar. Também farei algo mostrando as qualidades do TDD, porque ele tem muitas, e acima já foi dito boa parte do que precisa ser dito sobre elas. Por isso, não vou falar mais.
Só porque está dito por alguém, não significa que é bom para você.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).