私のクラスはこの構造に従っています
サービス層のJUnitテストを作成すると、DAO層が呼び出され、実際のDB接続とDBからのデータの取得が期待されます。
DAO層をサービス層から完全にモックする必要がありますか、それともDB接続とDBから受信したデータをモックする必要がありますか？
次に、アプリはキャッシュから特定のデータを期待します。
JUnitランタイムの場合、キャッシュがないので、これをどのように処理する必要がありますか？サービス層メソッドには、詳細を取得するためのキャッシュの検索が含まれます。
回答:
Test Doublesについてお話します。この用語に出くわしていない場合は、Martin Fowlerの記事のリンクを最初に読んでおくとよいでしょう。
データベーステストの場合- 純粋な単体テストアプローチに従っている場合は、スタブまたはモックタイプのテストダブルを使用して、DB接続とその応答を模擬します。Mockを使用している場合は、Mockito、JMock、またはその他のお気に入りのモックツールを使用することをお勧めします。ただし、データベースなどの大規模なサードパーティのリソースをテストする場合、これは非常に面倒です。
データベーステストの場合-単体テストのやや緩い定義に従っている場合は、偽のテストダブルを使用できます。特定のケースでは、これはHSQLなどのメモリ内データベースになります。これは、データベース層を「単体」でテストする非常に一般的な方法です。これは単体テストではなく、代わりに統合テストであると主張する人もいます。私はそれは実際には大丈夫だと思います-問題の事実はあなたのコードを削除するいくつかのテストがあります:-)
キャッシュテストの場合- キャッシュAPIの複雑さによっては、Test Doubleのスタブスタイルがお勧めです。
HTH！
要約では、答えは非常に簡単です。
3つのレイヤーがあります。
[テストケース]-> [テスト中の動作]-> [その動作で使用される共同作業者]
3番目のレイヤーはモックされるべきものです。例えば：
PokemonCaptureServiceTest;PokemonCaptureService;Pokeballこの例でPokeballは、サードパーティのロジックであることがわかります。データベース接続やプロパティファイルなど、あらゆる種類の配管が必要です。サードパーティが適切にテストしていると信頼しているため、のテストから除外しますPokemonCaptureService。したがって、それはあざける必要があります。
ただし、別の場所では、コラボレーターPokeballは単純なクラスであり、テストケースの複雑さはほとんどなく、簡単にテストに含めることができます。この場合Pokeball、PokemonCaptureServiceテスト対象のインスタンスにの実際のインスタンスを含めることを決定できます。
厳格な規則はありません。自分に最適と思われる方法でテストを設計するのは、あなた次第です。あなたの目的は、正確で保守可能なテストをできるだけ早く作成することです。ここでの経験が鍵となります。より多くのテストを書いてください。そうすれば、すぐにそれに対する直感が得られます。
質問から判断すると、どこにでもいるので、何をテストしたいのか正確に判断するのは困難です。したがって、物事をあざける方法についての記事にあなたを導く以外に、どのように進めるかについての実用的な例をあなたに与えることは難しいです。したがって、より具体的にして、少し分割する必要があります。
キャッシュが正しく機能するようにテストしますか？
特にDB呼び出しをテストしますか？
アプリをテストして、キャッシュが正しく使用されるようにしますか？
テストするユニットを正確に決定したら、モックするものを簡単に選択できます。純粋なユニットテストでは、「テスト中のユニット」以外はすべてモックする必要があります。この背後にある理論的根拠は、モックに対するセットアップの期待から、テスト済みのユニットが正常に機能することを確認できるということです。
それ以外に、統合テストであるJUnitでいくつかのテストを記述したい場合があります。つまり、モックの使用を減らします。それらがソフトウェア設計が正しいかどうかを確認するための健全性チェックとして使用されている場合でも、それらはもろくなり、常にアプリまたはシステムの正確な問題を示すものではないことに注意してください。