TDD sempre? Quando o teste-primeiro ajuda e quando atrapalha

Resposta esperada

TDD rende quando você entende bem o comportamento esperado mas não a implementação: lógica de negócio com regras claras, bugs (escrever o teste que reproduz, depois corrigir), refatoração (rede de segurança primeiro), e APIs onde escrever o teste primeiro força você a projetar a interface pelo ponto de vista de quem usa. TDD atrapalha (ou pelo menos rende menos) quando o problema é exploratório: você está descobrindo COMO fazer (spike de integração com uma API nova, tuning de algoritmo, protótipo de UI) — aí escrever teste antes é testar um design que vai mudar dez vezes. Caminho comum: spike sem teste pra aprender, joga fora o código do spike, reimplementa com TDD. O importante é o código acabar testado; a ordem é ferramenta, não dogma.