ユニットテスト、機能テスト、受け入れテスト、統合テストの違いは何ですか? [closed] 質問する

どこを調べるかによって、答えは少しずつ異なります。私はこのテーマについてたくさん読んできましたが、私の結論は次のとおりです。繰り返しますが、これらは少し曖昧で、他の人は同意しないかもしれません。

ユニットテスト

機能の最小単位、通常はメソッド/関数をテストします (例: 特定の状態のクラスが与えられた場合、そのクラスで x メソッドを呼び出すと y が発生する)。ユニット テストは、特定の 1 つの機能に焦点を当てる必要があります (例: スタックが空のときに pop メソッドを呼び出すと、 がスローされるInvalidOperationException)。それが触れるものはすべてメモリ内で実行される必要があります。つまり、テスト コードとテスト対象のコードでは次のことが行われてはなりません。

• （重要でない）協力者に呼びかける
• ネットワークにアクセスする
• データベースにアクセスする
• ファイルシステムを使用する
• スレッドを紡ぐ
• 等

遅い/理解/初期化/操作が難しい依存関係は、適切な手法を使用してスタブ化/モック化/その他何らかの方法で作成する必要があります。そうすることで、依存関係が何をしているかではなく、コード単位が何をしているかに集中できるようになります。

要するに、ユニット テストは可能な限り単純で、デバッグしやすく、信頼性が高く (外部要因が少ないため)、実行が速く、プログラムの最小の構成要素が組み立てられる前に意図したとおりに機能することを証明するのに役立ちます。注意すべき点は、個別には完璧に機能することを証明できても、コードの単位を組み合わせると爆発する可能性があることです。これが次の理由です...

統合テスト

統合テストは、単体テストに基づいて、コードのユニットを組み合わせ、その結果が正しく機能するかどうかをテストします。これは、1 つのシステムの内部、または複数のシステムを組み合わせて何か役に立つことを行うもののいずれかです。また、統合テストと単体テストを区別するもう 1 つの要素は環境です。統合テストでは、スレッドを使用したり、データベースにアクセスしたり、すべてのコードとさまざまな環境の変更が正しく機能することを保証するために必要なことはすべて実行できます。

シリアル化コードを作成し、ディスクに触れずにその内部をユニットテストした場合、ディスクにロードして保存するときにそれが機能することをどうやって確認するのでしょうか。ファイルストリームをフラッシュして破棄するのを忘れたのかもしれません。ファイル権限が間違っていて、メモリストリームを使用して内部をテストしたのかもしれません。確実に確認する唯一の方法は、本番環境に最も近い環境を使用して「実際に」テストすることです。

主な利点は、ユニット テストでは検出できないバグ (たとえば、クラス A のインスタンスが予期せずクラス B の null インスタンスを受け取る) や環境バグ (私のシングル CPU マシンでは問題なく動作するが、同僚の 4 コア マシンではテストに合格できない) などを検出できることです。主な欠点は、統合テストではより多くのコードが処理され、信頼性が低く、障害の診断が難しく、テストの保守が難しくなることです。

また、統合テストは必ずしも完全な機能が動作することを証明するものではありません。ユーザーは私のプログラムの内部の詳細を気にしないかもしれませんが、私は気にします。

機能テスト

機能テストは、特定の入力の結果を仕様と比較することで、特定の機能の正確性をチェックします。機能テストは中間結果や副作用には関係なく、結果のみに関係します (x を実行した後、オブジェクト y の状態が z であることは関係ありません)。これらは、「関数 Square(x) を引数 2 で呼び出すと 4 が返される」などの仕様の一部をテストするために作成されます。

受け入れテスト

受け入れテストは 2 つのタイプに分かれているようです。

標準的な受け入れテストでは、完全なシステムでテストを実行し (たとえば、Web ブラウザー経由で Web ページを使用する)、アプリケーションの機能が仕様を満たしているかどうかを確認します。たとえば、「ズーム アイコンをクリックすると、ドキュメント ビューが 25% 拡大されます。」結果に実際の連続性はなく、合格または不合格の結果のみになります。

利点は、テストが平易な英語で記述され、ソフトウェア全体の機能が完全であることを保証できることです。欠点は、テストピラミッドの別のレベルに移動することです。受け入れテストは山のようなコードに触れるため、障害を追跡するのは困難です。

また、アジャイル ソフトウェア開発では、ユーザー受け入れテストには、開発中にソフトウェアの顧客によって作成されたユーザー ストーリーを反映するテストの作成が含まれます。テストに合格すると、ソフトウェアは顧客の要件を満たし、ストーリーは完了したとみなすことができます。受け入れテスト スイートは、基本的にドメイン固有言語で記述された実行可能な仕様であり、システムのユーザーが使用する言語でテストを記述します。

結論

これらはすべて補完的です。 場合によっては、1 つのタイプに焦点を当てたり、完全に避けたりすることが有利です。 私にとっての主な違いは、一部のテストはプログラマーの視点から物事を見ているのに対し、他のテストは顧客/エンド ユーザーに焦点を当てていることです。