3

最近、同僚と私はJavaプロジェクトの統合テストを書いています。これらの統合テストのほとんどは、少なくとも1つのSOAP Webサービス呼び出し、LDAPクエリ、または必ずしも制御できないエンドポイントに依存するその他のものを必要とします。これらのSOAP/LDAP呼び出しの一部は、まだ開発中のlibsを使用します。

これが意味することは、マシンがダウンしたり、ライブラリが変更されたり、エンドポイントが変更されたりしたときに、ビルド中に統合テストが失敗することがあるということです。いくつかの調査を行った後、統合テストでライブエンドポイントを使用することがかなり一般的であることに気付きましたが、ライブエンドポイントの使用が有害である理由についての記事も見つけました（http://martinfowler.com/articles/nonDeterminism.html #RemoteServices）。

統合テストを作成するときに、すべてのエンドポイントをモックするのか、ライブエンドポイントを使用するのか、どちらがより理にかなっているのでしょうか。特に信頼性が低い場合にライブエンドポイントを使用すると、テストが非決定的になるようです。ただし、モックはこれまでのところしか理解できないようであり、本番環境のような環境で何が起こるかをテストすることはできません。純粋なモックで構成された統合テストは、回帰以外のものを検証するのに役立ちますか？

4

2 に答える 2

5

モックしてエンポイントするときは、エンドポイントを正確にモックすることが非常に重要です。そうしないと、テストによって、サービスと適切に統合できると誤って信じてしまう可能性があります。変化しているエンドポイントで作業しているという事実は、これを困難にしているように思われます。

統合テストレベルでも受け入れテストレベルでも、実際のエンドポイントと相互作用するテストを行う必要があります。そうしないと、統合が実際に機能するかどうかがわかりません。

たとえば、ライブラリが変更されたり、エンドポイントが変更されてテストが失敗した場合、それは実際には統合の失敗であるため、検出するのは良いことです。マシンがダウンした場合、テストでそれを検出し、これに失敗するのではなく、スキップされたものとしてテストを報告できます。

したがって、この場合、実際のサービスを使用して、ソフトウェアがサードパーティのコンポーネントと適切に統合されていることを確認します。

于 2013-03-07T03:24:14.883 に答える
2

あなたは間違いなくあなたのエンドポイントをモックすることを試みるべきです。これを行う理由はいくつかあります。

  • パフォーマンスが重要、
  • 実稼働環境にストレスがない、または
  • いくつかのバグが検出された場合、なぜ本番環境を壊すのですか？

この問題の詳細については、このブログをご覧ください。

于 2016-03-18T11:52:10.657 に答える