42

統合テストに必要な多くの依存関係をどのように模倣しますか？

私は「純粋な」単体テストにMockitoを使用しています。この場合の「純粋」とは、単一のクラスをテストし、そのすべての依存関係をモックすることを意味します。美しい。

次に、統合テストが行​​われます。この場合、統合テストは次のようなものをテストするとします。

  1. メッセージがキューに入れられます
  2. メッセージは「処理済み」です
  3. 応答メッセージは応答キューに入れられます

また、ステップ2で行われる処理は深刻なものであるとしましょう。それは、多くのデータベースの相互作用、複数の外部サービス、ファイルシステム、あらゆる種類のものに依存しています。フローがトリガーする副作用もたくさんあるので、応答が正しいことを単純に確認することはできません。副作用を確認する必要があります。

これらの各依存関係は、単一のステートレスサービスクラスによってラップされているため、それらは素晴らしく、モック可能です。

人々はこれをどのように扱っていますか？

上記のフローの副作用を確認できるように、Mockitoを使用したいと思います。ただし、Mocktioのドキュメント（およびその実装の大部分）は、「純粋な」単体テスト以外のコンテキストでの使用に強く反対しているようです。私はこのルートに行こうとしましたが、

  • スタブデータを入力するのは困難です（データがたくさんあるため）
  • これらのスタブされたインスタンスをSpringにBeanに注入させるのは困難です
  • スタブをクリアせずに別の相互作用のセットを検証できるように、モックを「リセット」することは困難です。

編集

HSQLDBインスタンスのようなものでデータベースの問題を処理できることは知っていますが、外部サービスの問題はまだあります。再現性のために、これらのサービスが稼働していること、必要な状態にあることなどに依存することはできません。私が見る唯一のオプションは、それらをモックすることです。

なに？

4

3 に答える 3

12

素晴らしい質問です。

Mockitoの限界に達したようです。Mockitoは、オブジェクトの相互作用を検査したい場合に最適です。

ただし、必要なのは、より高いレベルの抽象化での可観測性（および可制御性）のようです。そのために必要なモックやスタブは、慎重に設計して手作りする必要があります。

ユニットレベルでは、これらのモックはMockitoを使用してうまく生成できます。統合レベルでは、これははるかに困難になり、専用のテスト容易性インターフェースが必要になります。

于 2012-04-14T10:11:19.350 に答える
8

データベース、Webサービス、ファイルシステムなどをモックするために、おそらく少しリファクタリングする必要があります。外部サービスごとに、実行する操作ごとのメソッドを持つラッパークラスを作成する必要があります。このような各メソッドには実際のロジックはありませんが、外部サービスが理解できるようにパラメーターを渡し、外部サービスが返すデータを含むオブジェクトを返します。たとえば、データベースを操作している場合、ラッパークラスはそのパラメーターをSQLステートメントにフォーマットし、既存のConnectionオブジェクトに送信してList、結果のを返す場合があります。

ラッパークラスのメソッドにはロジックが含まれていないため（つまり、if / else、ループ、例外処理はありません）。ラッパークラスを単体テストする必要はありません。ラッパークラスの統合テストを行って、その責任が正しく実行されていることを確認する必要があります（つまり、SQLステートメントがデータベースに望ましい効果をもたらすことを確認します）。

次に、外部サービスと相互作用するクラスを書き直して、代わりにラッパークラスと相互作用するようにします。そうすれば、それらを単体テストするのは簡単です。ラッパークラスをモックするだけです。

于 2012-04-13T06:31:15.623 に答える
-2

httpまたはRESTモックフレームワークがある場合は、それを使用することをお勧めします。

複雑な依存関係はすべて、記録、変更、および再生できます。

于 2016-10-29T22:08:35.090 に答える