私は過去にこの話題について話し合ったことがあり、答えを知っているかもしれないと思いますが、それを適切に表現することができませんでした.
私が知っていると思うことは次のとおりです。
テストを書く前に物事がどのように機能するかを頭の中にすでに持っている場合、あなたはテスト主導ではなくテスト主導であると思われます。つまり、実装のアイデアが最初に来て、テストがどのように見えるかを決定します。
テスト駆動型の場合は、実装がどのように見えるかをテストに駆動させようとしています。実装の先入観ではなく、必要な動作のテストを作成するため、テストに合格するには「リファクタリング」段階で実装を考え出す必要があります。
私の質問は次のとおりです。
テスト駆動開発の重要な側面は、テストに合格する必要のない機能を実装しないことです。テストファーストとは、機能を実装する前にテストを書くことを意味します。これは主に、機能が存在しない場合にテストが実際に失敗することを確認するために行われます。テスト駆動開発は、テスト ファーストのアプローチを意味しますが、その逆ではありません。
あなたはテスト ファーストとテスト駆動の違いを十分に理解し、明確に説明したと思います。Björn が指摘するように、すべてのテスト駆動開発は必然的にテスト ファーストです。テスト優先の考え方からテスト駆動型の考え方に移行する方法についての質問に対しては、比較的単純な演習 (Range または Rectangle の実装など) を数回行い、毎回異なる実装に到達することをお勧めします。最初に、あなたは今考えていることを思いつくでしょう - そしてそれはあなたが指摘するように、テスト主導ではありません. 次回は、現在考えていることを使用することはできません。何か別のものを考え出すために手を差し伸べる必要があり、その手の届く範囲の一部は、失敗したテストの存在下で発生します。たぶん、3回目で、あなたは'
演習が気に入らない場合は、最初のテストをもっと早く書いてみてください。事前に分析を行わないでください。問題に取り組むときは、まずテストを書きます。これで、「肩越しに見る」テストで問題について考えることができます。しばらくは不快になるだろうが、不快感から抜け出して、問題を見る新しい方法 (そして私は良い方法だと思う) が現れるはずだ.
違いは、役割とインターフェースの検出です。
テストファーストでは、テストを作成する前に、設計にジャンプする可能性があります（これは、スキルに基づいて、最も単純/最適な選択である場合とそうでない場合があります）。テストファーストは、既存の悪い設計に対してテストを行うのも簡単ですが、進行は遅くなります。テストが難しいコードや書き込みが遅いテストになってしまう可能性があります。
IMHOテスト駆動は、テストが簡単な、より単純な設計を作成するのに役立ちます。
考え方に入る方法は？：それはあなたが自己規律と練習を必要とする部分です。はい、解決策への競争からあなたの心を保つことは難しいです。探索モードでいくつかのコード型を実行することを指してくれたCarlに+1し、さまざまな選択をして、それがどのように終わるかを確認します。あなたのベルトの下にいくつかあると、それはより簡単になります...TDDは実際にあなたが一度に一つのことに「集中」するようにします。
実装前に一連のテストを作成すると、パブリック メソッドの単体テストを作成できます。したがって、何が起こっているかの実際の実装は、テストから隠されています。良いこと（TM）である実装ではなく、抽象にコーディングしています。抽象的な用語と概念を取り入れています-テストは、パブリックメソッドが何であるかを形成します。したがって、テスト駆動とは、テストが API を駆動することを意味します。逆は、テストファーストと呼ばれるものです。