単体テスト？統合テスト？回帰テスト？受け入れテスト？

TDDまたは単体テストを行うときに区別するのが難しいので、これらのレベルのテストを明確に定義できる人はいますか？誰がどのように、いつこれらを実装するかについて詳しく説明できる場合はどうですか？

簡単に：

単体テスト -個々のコードを単体テストします。各ファイルまたはクラスについて考えてください。

統合テスト -相互作用する複数のユニットを組み合わせる場合、統合テストを実施して、これらのユニットを統合してもエラーが発生しないことを確認する必要があります。

回帰テスト -統合（およびおそらく修正）した後、ユニットテストを再度実行する必要があります。これは回帰テストであり、それ以上の変更によってすでにテスト済みのユニットが破損していないことを確認します。すでに行った単体テストにより、回帰テストのために何度も実行できる単体テストが作成されました。

受け入れテスト -ユーザー/顧客/ビジネスが機能を受け取ると、ユーザー（またはテスト部門）が受け入れテストを実施して、機能が要件を満たしていることを確認します。

ホワイトボックスとブラックボックスのテストを調査することもできます。また、パフォーマンスと負荷のテスト、および考慮すべき「問題」のテストもあります。

単体テスト：失敗すると、修正が必要なコードの部分がわかります。

統合テスト：失敗すると、アプリケーションの各部分が期待どおりに機能していないことがわかります。

受け入れテスト：失敗した場合、顧客が期待することをアプリケーションが実行していないことがわかります。

回帰テスト：失敗すると、アプリケーションは以前のように動作しなくなることが通知されます。

上記の各テストの簡単な説明と、それらがいつ適用されるかを次に示します。

ユニットテスト ユニットテストは、自己完結型のユニット（通常はクラスまたはメソッド）で実行され、ユニットが実装されたとき、またはユニットの更新が完了したときに実行する必要があります。

これは、クラス/メソッドを記述し、バグを修正し、機能を変更したときに実行されることを意味します...

統合テスト 統合テストは、複数のユニットが相互にどのように相互作用するかをテストすることを目的としています。このタイプのテストは、ユニット間で新しい形式の通信が確立されたとき、またはユニットの相互作用の性質が変更されたときに実行する必要があります。

これは、最近書き込まれたユニットがシステムの残りの部分に統合されたとき、または他のシステムと相互作用するユニットが更新されたとき（およびそのユニットテストが正常に完了したとき）に実行されます。

回帰テスト 回帰テストは、システムに変更が加えられるたびに実行され、新しいバグが導入されていないことを確認します。

つまり、すべてのパッチ、アップグレード、バグ修正の後に実行されます。回帰テストは、単体テストと統合テストを組み合わせた特別なケースと見なすことができます。

受け入れテスト 受け入れテストは、サブシステム（場合によってはシステム全体）が仕様全体を満たしていることを確認する必要がある場合に実行されます。

これは、主に、新しい成果物を完了する前、またはより大きなタスクの完了を発表する前に実行されることを意味します。これを最終チェックとして見て、クライアント/ボスに向かって勝利を発表する前に、本当に目標を達成したことを確認します。

これは少なくとも私が学んだ方法ですが、他の反対する見方があると確信しています。いずれにせよ、それが役に立てば幸いです。

私が試してみます：

1. 単体テスト：開発者は、個々のコンポーネントまたはクラスをテストするために1つ作成します。
2. 統合テスト：コラボレーションする必要のあるいくつかのコンポーネントまたはパッケージを含む、より広範なテスト
3. 回帰テスト：アプリケーションに1つの変更を加えると、すべてのテストを再実行してすべての機能をチェックアウトする必要があります。
4. 受け入れテスト：アプリケーションの配信を受け入れるためにサインオフする前に、エンドユーザーまたはQAがこれらを行います。「アプリは私の要件を満たしました」と書かれています。

単体テスト：私の単一のメソッドは正しく機能していますか？（依存関係がない、または依存関係が模造されている）

統合テスト：別々に開発した2つのモジュールを組み合わせると、正しく機能しますか？

回帰テスト：新しいコードを変更/作成することで何かを壊しましたか？（すべてのコミットでユニット/統合テストを実行することは、技術的に（自動化された）回帰テストです）。QAのコンテキストでより頻繁に使用されます-手動または自動。

受け入れテスト：クライアントによって行われたテスト、彼は提供されたソフトウェアを「受け入れる」

コメントできない（評判が低い：-|）ので...

@Andrejsは、各タイプのテストに関連付けられた環境間の違いについて良い点を示しています。

単体テストは、通常、開発者のマシンで（そしておそらくCIのビルド中に）実行され、他のリソース/システムへの依存関係がモックアウトされます。

定義による統合テストには、（ある程度）依存関係の可用性が必要です。他のリソースとシステムが呼び出されるため、環境がより代表的になります。テスト用のデータは、モック化されているか、実際の本番データの小さな難読化されたサブセットである可能性があります。

UAT /受け入れテストは、ソフトウェアを受け入れるQAおよびビジネスチームに実際の経験を表す必要があります。そのため、現実的なパフォーマンスとエンドユーザーエクスペリエンスを提供するには、完全な統合と現実的なデータボリューム、および完全なマスク/難読化されたデータセットが必要です。

パフォーマンステスト、セキュリティなど、他の「問題」も、実稼働体験をシミュレートするために、できるだけ現実に近い環境を必要とする可能性があります。