Daoクラスを呼び出すビジネスクラスをテストするJunitテスト

Question

StrutsとプレーンなJDBCフレームワークを使用して実装されている製品を引き継ぎます。私はテストをスピードアップするためにプロジェクトにJunitテストを実装する予定です。 FYI、このプロジェクトはまだ生産されていません。これはまだ開発段階ですが、非常に古い技術を使用しています。プロジェクトには、インタフェースとそれぞれの実装がありません。ような古いプログラミングは、クラスは直接インスタンス化され、そのように使用されます。だから、mockitoフレームワークを使用することはできません。これらすべての制限を受けて、私はプロジェクトにTDDを開発する必要があります。私は新しい技術でそれを完全に廃止して開発することはできません。

私の質問は、ビジネスメソッドが機能しているかどうかを確認するjunitテストを書いています。このビジネスクラスもDAOを呼び出しています。テスト時にDB接続が作成されていないため、接続エラーが発生します。ビジネス層のみをテストするjunitテストを作成するにはどうすればよいですか？テストメソッドにDAO接続を含める必要がありますか？はいの場合、これをどのように達成するのですか？

私はJunitとTDDの初心者です。私の理解が間違っている場合や、これを修正する場合は、私を案内してください。

Answer 1

私は何か他のことを行う前に、テスト可能な状態にリファクタリングすることをお勧めします。あなたが言ったようにデザインが本当に壊れている場合は、特定のクラスのための便利なテストを書く方法があります。

Answer 2

コードをリファクタリングできますか？もしそうなら、コードをリファクタリングして、実際のDAO用のDAOインターフェイスを定義し、新しく作成されたインターフェイスの模擬バージョンを実装し、ユニットテストでサービスに注入することができます。

フレームワークなしでDAOをサービスクラスに挿入する最も簡単な方法は、コンストラクタインジェクション、つまりDAOインスタンスをサービスクラスコンストラクタに渡すことです。

public class YourService { 
    private final YourDAOInterface dao; 

    public YourService(YourDAOInterface dao) { 
     this.dao = dao; 
    } 
} 

ここでコンストラクタdaoのパラメータは（あなたがそれらの2 DAOは、同じインターフェイスYourDAOInterfaceを実装するために必要な）テストのための本当のDAO、またはモック実装することができます。

Answer 3

私が推測するように、あなたの記事の最初の段落は、最終的に第2段落で尋ねた質問とは関係ありません。

私たちはユニットテストをユニットテストと呼んでいます。なぜなら、ユニットテストは統合テストではないからです。ここでレイヤーを混在させません。

ビジネスレイヤのみをテストすることを目標とする場合は、ビジネスレイヤのみをテストし、下のすべてを模倣します（DAOなど）。したがって、いくつかの模擬フレームワーク（Mockito、PowerMock、JMockitなど）を使用してビジネスレイヤーコードにデータを提供し、DAOレイヤーが正しいと仮定します。

mockingフレームワークを使用することにより、DAOレイヤがデータベースからハンドオーバーする予定のビジネス関数に同じデータを提供し、DAOレイヤをまったく実行しません。ユニットテストを適切に記述するために、JUnitに加えてこれらの模擬APIが必要になります。

In Memoryデータベースとフレームワーク（Apache DBUnitとH2 DBはあります）を使用することについてのご意見はお答えしますが、DAOレイヤーの単体テストを記述する際には必要です。

他の回答で示唆されているように、リファクタリングとコードをテスト可能にすることが常に推奨されます。

希望すると助かります！