単体テストとテスト駆動開発の違い
説明を読むと、TDDテストは関数を記述する前に行われ、ユニットテストは関数を後で行うことがわかります。
これが主な違いですか、それとも2つの用語を比較することさえできませんか？おそらく、単体テストはTDDの統合された部分です。
単体テストはwhatを参照します[〜＃〜] tdd [〜＃〜] to whenを参照しますあなたはテストしています。
2つは直交しています。
ユニットテストとは、個々の動作ユニットをテストすることです。個々の動作単位は、個別に個別にテストできる可能な最小の動作単位です。 （私はこれら2つの定義が循環していることを知っていますが、実際には非常にうまく機能しているようです。）
コードを記述する前、コードを記述した後、またはコードを記述している間にユニットテストを記述できます。
TDDは、テストを開発（およびデザイン）に駆り立てることを意味します（これも、ある程度明白です）。単体テスト、機能テスト、受け入れテストでそれを行うことができます。通常、3つすべてを使用します。
TDDの最も重要な部分は中間[〜＃〜] d [〜＃〜]です。テストを許可しますドライブあなた。テストは、完了したら、何をすべきか、次に何をすべきかを教えてくれます。 APIがどうなるか、デザインが何であるかを教えてくれます。 （これは重要です。TDDは最初にテストを作成することではありません。最初にテストを作成するがTDDを実践しないプロジェクトはたくさんあります。最初にテストを作成することは、テストが開発を推進できるようにするための前提条件にすぎません。）
ユニットテストはテスト駆動開発のコンポーネントです
テスト駆動開発を行わなくても単体テストを実行できます。ただし、単体テストを使用せずにテスト駆動開発を行うことはできません。
従来の単体テストを行う場合、テストを記述した後コード。
テスト駆動開発アプローチは、ユニットテストbeforeの前にコードを書くことです。
単純な単体テストと比較したTDD（IMHO）の最も興味深い利点：
- コードは完全にテスト済みのコードです。簡単なテストです。
- クラスを正しく設計する必要があります。
- また、 単純な愚かさを保つ を強制します。
- Red-Green-Refactorのサイクルは絶対的な先延ばしのキラーです！
TDDと単体テストは、しばしば誤用される2つの非常に具体的な用語です。
TDDは、失敗するテストを記述し、それを実行するために必要な最小限のコードを記述し、コードをリファクタリングしてクリーンにします。これは、失敗->成功->リファクタリングのサイクルで行われ、コードの既知の要件ごとに新しいテストが追加されます。最近では、TDDは、そのサイクルで単体テストを作成することについてさらに具体的になり、同様のサイクルで受け入れテストを作成しているATDD（BDDのサブセット）と区別しています。
ユニットテストとは、小さな独立したユニットでコードをテストすることです。ここでよくある混乱は、xUnitやRspecなどの単体テストツールを使用して、単体テストを作成しているテストを実行していると考えることです。これは必ずしも真実ではありません。これらのツールは、Seleniumフレームワークを使用して言うテストを実行するために使用できます。その場合、単体テストランナーを使用して受け入れテストを記述します。単体テストは非常に具体的には、速度を上げるために他のすべてのものから分離された小さなロジックに焦点を合わせたテストです（そのため、テストを頻繁に実行し、新しいバグに関する迅速なフィードバックを得ることができます）。
TDDは、あなたが言ったように開発の前にテストケースを書くアプローチであり、開発者はテストケースをパスするコードを記述します。ユニットテストは、システムテスト、統合テスト、受け入れテスト以外の範囲が狭いタイプのテストを表すために使用される用語です。
TDDは、コードを作成するための哲学的アプローチです。最初にテストを作成します。あなたが書くテストはユニットテストです。
すべての優れた答え。単体テストは「単体」を小さなコンポーネントと見なす傾向があることを付け加えますが、TDDは統合テストと受け入れテストを含むように拡張されます。
（一部のTDDバリアントは、「ユニット」を目的の機能に向けた最小の増分ステップと見なします...）
2つを分離する方法は、TDDはテストではなく、コードの設計にあると考えることです。次に、単体テストを使用して、終了コードの期待値を設定します。終了コードが記述され、テスト（仕様）に合格すると、テストを使用して設計されたコードが作成されます。