単体テストとテスト駆動開発の違い

説明を読むことで、TDDテストでは関数を記述する前に行われ、ユニットテストでは後に行われることを理解しています。

これが主な違いですか、それとも2つの用語を比較することすらできませんか。おそらく、ユニットテストはTDDに統合された部分です。

ユニットテストは、を意味し何をテストしている、TDDにするとき、あなたがテストしています。

2つは直交しています。

ユニットテストとは、まあ、個々の動作ユニットをテストすることです。個々の動作単位は、個別に個別にテストできる可能な最小の動作単位です。（これら2つの定義は循環的ですが、実際には非常にうまく機能しているようです。）

コードを書く前、コードを書いた後、またはコードを書いている間にユニットテストを書くことができます。

TDDとは、テストが開発（および設計）を促進することを意味します。単体テスト、機能テスト、受け入れテストでそれを行うことができます。通常、3つすべてを使用します。

TDDの最も重要な部分は、中央のDです。テストを駆使してください。テストは、完了したら、何をすべきか、次に何をすべきかを示します。彼らはAPIがどうなるか、デザインは何かを教えてくれます。（これは重要です。TDDは最初にテストを書くことではありません。最初にテストを書くがTDDを実践しないプロジェクトがたくさんあります。最初にテストを書くことは、テストが開発を推進できるようにするための前提条件です）

単体テストはテスト駆動開発のコンポーネントです

テスト駆動開発を行わずに単体テストを実行できます。ただし、単体テストを使用せずにテスト駆動開発を行うことはできません。

従来の単体テストを行う場合、コードを記述した後にテストを記述します。

テスト駆動開発アプローチは、コードを書く前に単体テストを書くことです。

単純な単体テストと比較したTDD（IMHO）の最も興味深い利点：

• コードは完全にテスト済みのコードです。テストは簡単です。
• クラスを正しく設計する必要があります。
• また、単純な愚かさを維持することを強制します。
• Red-Green-Refactorのサイクルは絶対的な先延ばしキラーです！

TDDと単体テストは、非常に特殊な2つの用語であり、しばしば誤用されます。

TDDは失敗するテストを作成してから、実行に必要な最小限のコードを作成し、コードをリファクタリングしてクリーンにします。これはサイクルで行われ、失敗->合格->リファクタリング、コードの既知の要件ごとに新しいテストを追加します。さらに最近では、TDDは、そのサイクルで単体テストを記述することについてさらに具体的になり、同様のサイクルで受け入れテストを記述するATDD（BDDのサブセット）と区別しています。

単体テストとは、小さな孤立したユニットでコードをテストすることです。ここでの一般的な混乱は、xUnitやRspecなどの単体テストツールを使用して、単体テストを作成しているテストを実行していると考えることです。これは必ずしも真実ではありません。これらのツールは、Seleniumフレームワークを使用してsayテストを実行するために使用できます。その場合、単体テストランナーを使用して受け入れテストを記述します。単体テストは、特に高速化のために他のすべてから分離された小さなロジックに焦点を当てた非常に具体的なテストです（そのため、頻繁に実行し、新しいバグに関する迅速なフィードバックを得ることができます）。

あなたが言ったように、TDDは開発前にテストケースを書くアプローチであり、開発者はテストケースをパスするためにコードを書きます。ユニットテストは、システムテスト、統合テスト、受け入れテスト以外の狭い範囲のタイプのテストを説明するために使用される用語です。

TDDは、コードを記述するための哲学的なアプローチです。最初にテストを記述します。作成するテストは単体テストです。

2つを分離する方法は、TDDはテストではなく、コードの設計に関するものだと考えることです。次に、単体テストを使用して、終了コードの期待値を設定します。終了コードが作成され、テスト（仕様）に合格すると、テストを使用して設計されたコードが得られます。

すべての優れた答え。ユニットテストでは「ユニット」を小さなコンポーネントと見なす傾向がありますが、TDDは統合テストと受け入れテストを含めるようにスケールアップします。

（一部のTDDバリアントは、「ユニット」を目的の機能に向けた最小の増分ステップと見なします...）