0

他の 2 つのサービス間の仲介者として機能するサービスがあります。基本的に入力を検証し、(トランザクションの整合性を維持することによって) これらの 2 つのサービスに順番に渡し、すべてがうまくいけば、結果をデータベースに保存します。

私の問題は、このサービスを個別にテストすることです。もちろん、依存関係を満たすためにスタブを提供できます。入力の検証、通常の場合に適切なデータが DB に保存されるかどうか、依存関係のいずれかが例外をスローした場合にトランザクションの整合性が維持されるかどうかもテストできます。

ただし、これはサービスが実際に行うことの半分にすぎません。私のジレンマは、他の 2 つの依存関係サービスも実際にデータを適切に処理したかどうかを証明しようとするかどうかです。私のサービスの範囲は非常に広いので、依存サービスもうまく機能しているかどうかも知っておくとよいでしょう。しかし、これは単体テストの範囲から外れて、統合テストに移行しますよね?

私はここでちょっと混乱しています。

4

2 に答える 2

0

単体テストについて質問している場合、それを行う方法は、モックまたはスタブを使用してクラスを分離してテストすることです。

しかし、それだけでは不十分だと思われる場合は、テストしたいすべての実際のクラスを使用するいくつかのコンポーネントテストを記述し、スタブ (またはインメモリ) データベースを使用して、依存関係のいくつかをモックすることができます。テストしようとしているものにとって重要ではないと考えてください。

過去に、私はこの方法でクラス間の相互作用が高いクラスの小さなクラスターをテストしました (そして、コンポーネント テストがすべてのシナリオをカバーしていたため、それらのクラスの単体テストをスキップすることもありました)。明らかに、これを行う際の問題は、テストするクラスが増えるほど、シナリオの数がほぼ指数関数的に増加することです。おそらく、ブリッジとそのブリッジを使用する 2 つの実際のクラスをテストできます。

于 2013-07-24T08:40:29.777 に答える