単体テスト？統合テスト？回帰テスト？受入試験？
TDDや単体テストを行う際に区別するのが難しいため、これらのテストレベルを明確に定義できる人はいますか。誰がどのように、いつこれらを実装するのかを詳しく説明できる場合はどうか？
簡単に：
単体テスト-個々のコードを単体テストします。各ファイルまたはクラスを考えてください。
統合テスト-相互作用する複数のユニットをまとめる場合、統合テストを実施して、これらのユニットを一緒に統合してもエラーが発生しないことを確認する必要があります。
回帰テスト-統合（およびおそらく修正）後、ユニットテストを再度実行する必要があります。これは、さらなる変更が既にテストされたユニットを壊さないことを保証するための回帰テストです。既に実行した単体テストは、回帰テストのために何度も実行できる単体テストを生成しました。
受け入れテスト-ユーザー/顧客/ビジネスが機能を受け取ると、ユーザー（またはテスト部門）は受け入れテストを実施して、機能が要件を満たしていることを確認します。
ホワイトボックスとブラックボックスのテストを調査することもできます。また、パフォーマンスと負荷のテスト、および考慮すべき "'ilities"のテストもあります。
単体テスト：失敗すると、コードのどの部分を修正する必要があるかがわかります。
統合テスト：失敗すると、アプリケーションの各部分が期待どおりに連携して動作していないことがわかります。
受け入れテスト：失敗すると、顧客が期待することをアプリケーションが行っていないことを通知します。
回帰テスト：失敗すると、アプリケーションが以前のように動作しなくなったことを通知します。
私が試してみます：
- 単体テスト：開発者は、個々のコンポーネントまたはクラスをテストするために1つを作成します。
- 統合テスト：コラボレーションが必要な複数のコンポーネントまたはパッケージを含む、より広範なテスト
- 回帰テスト：アプリケーションに1つの変更を加えると、すべてのテストを再実行し、すべての機能をチェックアウトする必要があります。
- 受け入れテスト：エンドユーザーまたはQAは、アプリケーションの配信を受け入れるためにサインオフする前にこれらを行います。 「アプリは私の要件を満たしました。」と表示されます。
上記の各テストの簡単な説明と、それらが適用可能な場合を次に示します。
単体テスト単体テストは自己完結型ユニット（通常はクラスまたはメソッド）で実行され、ユニットが実装されるかユニットの更新が完了するたびに実行される必要があります。
これは、クラス/メソッドを記述し、バグを修正し、機能を変更するたびに実行されることを意味します...
統合テスト統合テストの目的は、複数のユニットが相互にどの程度相互作用するかをテストすることです。このタイプのテストは、ユニット間で新しい通信形式が確立されたとき、またはユニットの相互作用の性質が変わったときに実行する必要があります。
これは、最近書かれたユニットがシステムの残りの部分に統合されるたびに、または他のシステムとやり取りするユニットが更新されるたびに（およびそのユニットテストが正常に完了するたびに）実行されることを意味します。
回帰テスト回帰テストは、新しいバグが導入されていないことを確認するために、システムで何かが変更されるたびに実行されます。
つまり、すべてのパッチ、アップグレード、バグ修正の後に実行されます。回帰テストは、単体テストと統合テストを組み合わせた特別なケースと見なすことができます。
受け入れテスト受け入れテストは、サブシステム（おそらくシステム全体）が仕様全体を満たしているかどうかを確認するのに関連する場合に実行されます。
これは、主に新しい成果物を完了する前、またはより大きなタスクの完了を発表する前に実行されることを意味します。これを最終チェックとして見て、クライアント/ボスに駆け寄り勝利を発表する前にあなたが本当に目標を達成したことを確認してください。
これは少なくとも私が学んだ方法ですが、他の反対意見もあると確信しています。いずれにせよ、それが役立つことを願っています。
単体テスト：私の単一のメソッドは正しく機能していますか？ （依存関係がない、または依存関係がモックされている）
統合テスト：一緒に？
リグレッションテスト：新しいコードを変更/作成することで何かを壊しましたか？ （コミットごとにユニット/統合テストを実行することは、技術的に（自動化された）回帰テストです）。 QAのコンテキストでより頻繁に使用されます-手動または自動。
受け入れテスト：配信されたソフトウェアを「受け入れる」ことにより、クライアントによって行われたテスト