7

私は現在、今後のプロジェクトでテストをどのように実行すべきかを調査しています。開発プロセスの早い段階でバグを見つけるために、開発者は実際のコードの前に単体テストを作成します (TDDish)。単体テストは、必要に応じて単体 (この場合はメソッド) に焦点を当てるため、依存関係がモック化されます。

今、私はこれらのユニットが他のユニットと相互作用するときにもテストしたいと思っています.ユニットテストはすでに書かれているので、これを行うための効果的なベストプラクティスがあるべきだと考えていました. 私の考えでは、単体テストは再利用されますが、モックされたオブジェクトは削除され、実際のものに置き換えられます。私が今持っているさまざまなアイデアは次のとおりです。

  • モック オブジェクトを使用するかどうかを決定する各テスト クラスでグローバル フラグを使用します。このアプローチには、いくつかのifステートメントが必要です
  • 「instanceWithMocks」または「instanceWithoutMocks」のいずれかを作成するファクトリ クラスを使用します。このアプローチは、新しい開発者が使用するのが面倒で、追加のクラスが必要になる場合があります
  • 統合テストを単体テストから別のクラスに分離します。ただし、これには多くの冗長なコードが必要になり、テスト ケースの維持には 2 倍の作業が必要になります。

私の見方では、これらすべてのアプローチには長所と短所があります。これらのうちどれが好まれますか、またその理由は何ですか? また、単体テストから統合テストに効果的に移行するためのより良い方法はありますか? それとも、これは通常、他の方法で行われますか?

4

6 に答える 6

1

単体テストは統合テストとは別にする必要があるという他のほとんどの回答に同意します (オプション 3) 。

しかし、私はあなたの反論には同意しません:

[...] ただし、これ (統合テストからユニットを分離する) には 多くの冗長コードが必要であり、テスト ケースの維持には 2 倍の作業が必要になります。

テスト データを使用してオブジェクトを生成するのは大変な作業になる可能性がありますが、これはテスト ヘルパー クラス、別名ObjectMotherにリファクタリングできるため、ユニットおよび統合テストから使用できるため、冗長性は必要ありません。

単体テストでは、テスト対象のクラスのさまざまな条件を確認します。

統合テストでは、これらの特殊なケースをすべて再確認する必要はありません。代わりに、コンポーネントが連携して動作することを確認します。

例

例外がスローされる 4 つの異なる状況に対して単体テストを行うことができます。統合のために、4 つの条件すべてを再テストする必要はありません。統合システムが例外を処理できることを確認するには、1 つの例外関連の統合テストで十分です。

于 2013-04-02T16:13:10.977 に答える
1

モックの代わりに実際のオブジェクトを使用して単体テストを再利用することが、統合テストを実装するための正しいアプローチであるかどうかはわかりません。

単体テストの目的は、オブジェクトの基本的な正確性を外部から切り離して検証することです。モックは、その分離を確実にするためにあります。それらを実際の実装に置き換えると、実際には完全に異なるものをテストすることになります.オブジェクトの同じチェーンの大部分の正確性をテストすることになり、何度も冗長にテストすることになります.

統合テストを単体テストと区別することで、検証したいシステムの部分を選択できるようになります。一般に、構成、I/O、サードパーティ システムとの相互作用、 UI や、単体テストでカバーするのが難しいその他のもの。

于 2013-04-02T13:41:03.257 に答える
1

統合テストは、別の動作をテストしているため、単体テストとは異なるクラスにする必要があります。統合テストとは、すべてが連携して動作することを確認するときに実行するものだと私は考えています。アプリケーションの一部への入力を使用し、期待される出力が返されるようにします。

于 2013-04-02T13:26:57.910 に答える
1

ここでは、Ninject/Autofac/StructureMap などの IoC コンテナーが役立つ場合があります。単体テストはコンテナーを介してテスト対象のシステムを解決できます。モックまたは実際のオブジェクトが登録されているかどうかは、単に登録の問題です。ファクトリ アプローチに似ていますが、IoC コンテナはファクトリです。新しい開発者が理解するには少しトレーニングが必要ですが、これは複雑なシステムの場合に当てはまります。これの欠点は、登録シナリオがかなり複雑になる可能性があることですが、実際に試してみないと、システムが複雑すぎるかどうかを判断するのは困難です。これが、決定的な答えが見つからない理由だと思います。

于 2013-04-02T13:20:44.620 に答える
1

単体テストと統合テストの目的を台無しにしていると思います。単体テストは、単一のクラスをテストするためのものです。これは低レベル API です。統合テストは、クラスがどのように連携するかをテストしています。これは別の高レベル API です。通常、単体テストは異なるレベルのシステム ビューを表しているため、統合テストで再利用することはできません。Spring コンテキストを使用すると、統合テスト用の環境をセットアップするのに役立つ場合があります。

于 2013-04-02T13:29:53.520 に答える