>>675
どのフェーズや規模感で作り直し/やり直しを言ってるのか分かってないからざっくりとした反論しかできんのだがすまんな

テストファーストだろうがテストセカンドだろうが、テストは変更になりうる。
そうするとテストラストしか選択肢がなくなるのだが
開発途中でテスト作らない方針だと、かなり不安な中でコーディングし続けるハメにならんか？

開発途中に変更が起こった場合、変更箇所のテストは確かに無駄になるが
変更箇所以外のテストは、変更時に安全性を担保するのに役立つ。
また変更の度合いによっては、設計の変更→既存のテストの変更という形で再利用しやすい場合もある。

つまり変更の可能性がある→テストが全くの無駄ということではなく、コストを払う価値は見いだせると思う
(この辺りはTDDに限らずテスト一般の話だが、テスト＝無駄と言われるとこれ以降の話が続かないので)

そういう開発中の不安を抑える為に、多少のコストを払ってそこそこの安心や品質を得るのがコーディングとセットのテスト作成。
テストセカンドだと、実装→テスト作成という流れで、テスト作成の工数自体はテストファーストよりも抑えられるのだが
「あれ、このインターフェース使いづらいぞ」とか「この設計だとテストしづらいわ」みたいなのが
実装完了してテスト作ってみて初めて分かる、というリスクがあるので設計手法としてはテストファーストよりも劣る
使いやすく・テストしやすく作っていくようなアプローチをとれる設計手法がTDDの大きなメリット


振り出しに戻ってやり直すっていうのは
そもそもプロトタイプ＝変更しまくりが前提の話なら、たぶんテストファーストしないほうがコスト低い
プロトタイプなら作って捨てるから。
(作って使いまわす前提のE2E→拡張サイクリングな開発ならテスト作った方がよいかも)

そしてプロトタイプでもないのに莫大な変更が頻繁に求められるんだとしたら
そのプロジェクトはもうTDDとか言ってる場合じゃないような気がするぞ・・・