O ponto sobre criadores de linguagem é forte, difícil argumentar contra. Acho que o problema com TDD é exatamente o que você descreveu: vira ritual sem entendimento. A maioria aprende o como sem nunca entender o quando e o por que. Vou pesquisar SDD, o nome não me era familiar. Qual você diria ser a diferença fundamental entre os dois?
Respondendo a "Toda pesquisa de "melhores práticas" de engenha..." dentro da publicação TDD na prática: quem realmente pratica no dia a dia?
2
3
Não sei ainda :D
SDD é uma abstração de maior nível, você documenta sem codificar, não é intenção dele fazer o que as pessoas acham que o TDD faz, mas ele não faz.
Não sei se é uma boa solução e sei que ele não elimina a necessidade de TDD se o projeto tem como requisito interno fazer os testes, mas pode ajudar na decisão de não fazer TDD.
Eu demoro para tomar uma decisão, porque ao contrário da maioria, eu só adoto algo depois de ter certeza que vai ajudar.
1
Faz sentido SDD ser uma camada acima: se a especificação já deixa claro o comportamento esperado, parte da necessidade do TDD como ferramenta de design de interface some. O problema é que a maioria dos projetos não tem especificação boa o suficiente pra isso funcionar de verdade.
O que me interessa no seu ponto é justamente essa distinção entre TDD como ferramenta de design versus TDD como ferramenta de verificação. O primeiro exige mudança de mindset real. O segundo é mais fácil de justificar, mas entrega menos valor.
Você já viu algum projeto em produção onde SDD eliminou de fato a necessidade de testes unitários, ou ainda é teoria a ser validada?