Eu acho que há um equívoco aqui. No design de software, o design é muito próximo ao produto. Em engenharia civil, arquitetura, o design é desacoplado do produto real: há plantas que seguram o projeto, que depois são materializadas no produto acabado, e aqueles são separadas por enormes quantidades de tempo e esforço
.O TDD está testando o design. Mas todo projeto de carro e projeto de construção também é testado. As técnicas de construção são primeiro calculadas, depois testadas em escala menor e depois testadas em escala maior, antes de serem colocadas em um prédio real. Quando eles inventaram H-vigas e a carga, por exemplo, descanse que isso foi tentado e tentado novamente antes dele construir a primeira ponte com ele.
Projetos de carros também são testados, projetando protótipos, e sim, certamente ajustando coisas que não são exatamente certas, até que ele corresponda às expectativas. Parte deste processo é mais lento, porque, como você disse, você não pode mexer muito com o produto. Mas todo redesenho de um carro baseia-se em experiências aprendidas com os antigos, e cada edifício tem cerca de mil anos de fundamentos sobre a importância do espaço, luz, isolamento, força, etc. Detalhes são alterados e melhorados, tanto nos edifícios e em redesenhar para os mais novos.Além disso, as peças são testadas. Talvez não exatamente no mesmo estilo como software, mas peças mecânicas (rodas, ignitores, cabos) são normalmente medido e colocado sob estresse para conhecer os tamanhos estão corretos, não houve anormalidades são para ser visto, etc. Eles podem ser xrayed ou Laser- medidos, eles tocam tijolos para identificar os quebrados, eles podem ser realmente testados em alguma configuração ou outra, ou eles desenham uma representação limitada de um grande grupo para realmente colocá-lo em teste.
Essas são todas as coisas que você pode colocar em prática com o TDD.
E, de fato, o teste não é garantia. Os programas travam, os carros quebram e os prédios começam a fazer coisas engraçadas quando o vento sopra. Mas ... 'segurança' não é uma questão booleana. Mesmo quando você não pode incluir tudo, ser capaz de cobrir - digamos - 99% das eventualidades é melhor do que cobrir apenas 50%. Não testar e, em seguida, descobrir que o aço não se adaptou bem e é frágil e quebra no primeiro tapa de um martelo quando você acabou de colocar sua estrutura principal é um simples desperdício de dinheiro. Que existem outras preocupações que podem ainda prejudicar o edifício não tornam menos estúpido permitir que uma falha facilmente evitável reduza seu design.
Quanto à prática do TDD, isso é uma questão de equilíbrio. O custo de fazer isso de uma maneira (por exemplo, não testando e depois pegando as peças mais tarde), versus o custo de fazer isso de outra maneira. É sempre um equilíbrio. Mas não pense que outros processos de design não possuem testes e TDD.