サービス層とDAO層のあるアプリケーションのテストでは、何をモックする必要がありますか？

Question

私のクラスはこの構造に従っています

サービス層（InputDTOを作成してDBデータにマップ）
DAO層（実際にDB呼び出しを実行します）

サービス層のJUnitテストを作成すると、DAO層が呼び出され、実際のDB接続とDBからのデータの取得が期待されます。

DAO層をサービス層から完全にモックする必要がありますか、それともDB接続とDBから受信したデータをモックする必要がありますか？

次に、アプリはキャッシュから特定のデータを期待します。

JUnitランタイムの場合、キャッシュがないので、これをどのように処理する必要がありますか？サービス層メソッドには、詳細を取得するためのキャッシュの検索が含まれます。

Martijn Verburg · Accepted Answer

Test Doublesについてお話します。この用語に出くわしていない場合は、おそらく最初に Martin Fowlerの記事リンクを読みたいと思います。

データベーステストの場合-pure単体テストアプローチに従っている場合は、Stubを使用します。または、MockタイプのTest Doubleを使用して、DB接続とその応答をモックアウトします。 Mockを使用している場合は、Mockito、JMock、または他のお気に入りのモックツールを使用することをお勧めします。ただし、データベースなどの大規模なサードパーティのリソースをテストする場合、これはかなり面倒です。
データベーステストの場合-ユニットテストのやや緩い定義に従っている場合は、FakeTest Doubleを使用できます。特定のケースでは、これはHSQLなどのメモリ内データベースになります。これは、データベース層を「単体」でテストする非常に一般的な方法です。 Someは、これは単体テストではなく、代わりに統合テストであると主張します。私はそれは実際には大丈夫だと思います-問題の事実はあなたのコードを削除するいくつかのテストがあります:-)
キャッシュテストの場合-キャッシュAPIの複雑さによっては、StubスタイルのTest Doubleがお勧めです。

HTH！

Synesso · Answer

抽象的には、答えは非常に簡単です。

3つのレイヤーがあります。

[テストケース]-> [テスト中の動作]-> [その動作で使用される共同作業者]

3番目のレイヤーはモックされるべきものです。例えば：

PokemonCaptureServiceTest;
テストPokemonCaptureService;
これはPokeballを使用します

この例では、Pokeballがサードパーティのロジックであることがわかります。データベース接続やプロパティファイルなど、あらゆる種類の配管が必要です。サードパーティが適切にテストしていると信頼しているので、PokemonCaptureServiceのテストから除外します。したがって、それはあざける必要があります。

ただし、別の機会に、コラボレーターPokeballは、テストケースにほとんど複雑さをもたらさず、簡単にテストに含めることができる単純なクラスです。この場合、テストするPokeballインスタンスにPokemonCaptureServiceの実際のインスタンスを含めることを決定できます。

厳格なルールはありません。自分に最適と思われる方法でテストを設計するのは、あなた次第です。あなたの目的は、正確で保守可能なテストをできるだけ早く作成することです。ここでの経験が鍵となります。より多くのテストを書いてください。そうすれば、すぐにそれについて良い直感が得られます。

Spoike · Answer

質問から判断すると、いたるところにいるので、何をテストしたいのか正確に判断するのは困難です。したがって、物事をあざける方法についての記事にあなたを導く以外に、どのように進めるかに関する実際的な例をあなたに与えることは難しいです。したがって、より具体的にして、物事を少し分割する必要があります。

キャッシュが正しく機能するようにテストしますか？
特にDB呼び出しをテストしますか？
アプリをテストして、キャッシュが正しく使用されるようにしますか？

テストするユニットを正確に決定したら、モックするものの選択が簡単になります。純粋なユニットテストでは、「テスト中のユニット」以外はすべてモックする必要があります。この背後にある理論的根拠は、モックに対するセットアップの期待から、テストしたユニットが正常に機能することを確認できるということです。

それ以外に、統合テストであるJUnitでいくつかのテストを記述したい場合があります。つまり、モックの使用を減らします。それらがソフトウェア設計が正しいかどうかを確認するための健全性チェックとして使用されている場合でも、それらはもろくなり、常にアプリまたはシステムの正確な問題を示すものではないことに注意してください。