0

私たちの共同体には​​、いくつかの要求XMLを受け取り、JDBCを介してさまざまなStored Procecdures（SP）にアクセスし、データを処理し、いくつかの応答XMLで応答するサービスレイヤーがあります。最近、人々はSPからの応答をモックするためにJUnitテストでMockRunnerを採用し始めています。MockRunnerを使用してSPからのモック応答をセットアップするコードはひどいように見えます（これは私が開いた最初のランダムテストクラスです）：

    MockConnection connection = new MockConnection();
    MockContextFactory.setAsInitial();
    InitialContext context = new InitialContext();
    context.rebind(READ_PAYMENT_DATA_SOURCE, getDS());
    getDS().setupConnection(connection);
    m_csStatementHandler = connection.getCallableStatementResultSetHandler();
    m_csStatementHandler.clearResultSets();
    m_csStatementHandler.clearCallableStatements();
    m_csStatementHandler.setExactMatch(false);
 m_csStatementHandler.prepareReturnsResultSet(READ_PAYMENT, true);
    m_csStatementHandler.setExactMatch(false);
    m_csStatementHandler.setExactMatchParameter(false);
    Map parameterMap = new HashMap();
    parameterMap.put(new Integer(1), null);
    parameterMap.put(new Integer(2), null);
    parameterMap.put(new Integer(3), null);
    parameterMap.put(new Integer(4), null);
    m_csStatementHandler.prepareOutParameter(READ_PAYMENT, parameterMap);
    //Set up the cursor of applications for return.
    MockResultSet resultApps = m_csStatementHandler.createResultSet();  

    resultApps.addRow(getPaymentSchedule("E", "Monthly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("A", "Weekly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("R", "Yearly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("S", "Weekly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("W", "Monthly", new Short("1"),null,null,null,null,null,null,null));

    MockResultSet[] results = new MockResultSet[1];
    results[0] = resultApps;
    m_csStatementHandler.prepareResultSet(READ_PAYMENT, resultApps);

上記のコードは多くの理由でひどいですが、ストアドプロシージャからの応答を設定することの複雑さとオーバーヘッドを明確に示しています。

これまで、ストアドプロシージャを実際に呼び出すクラスを注入する代わりに、手動でロールされた依存性注入を使用してきました。私がしなければならないのは、モックSP呼び出し元クラス（SPの実際の実行を担当）を作成し、必要な応答データを設定することだけです。私はこの手法に非常に満足しており、実装の詳細を気にすることなくデータに焦点を合わせているため、上記よりもはるかに単純です。しかし、私の質問は、いつMockRunnerを使用したいのかということです。単体テストにはやり過ぎのようですが、統合やシステムテストの方が多いと思いますか？それでも、DIフレームワークを使用してSP呼び出し元クラスをスワップアウトし、ストアドプロシージャ呼び出しごとに上記のすべてのコードをセットアップする方が簡単だと思います。啓発してください！ありがとう

4

1 に答える 1

3

最終的には、一般的なモックの背後にある哲学を調べています。私は 2 セントを差し上げますが、主要なモッキング ライブラリについても言及したいと思います。たとえば、 Mockitoを見てみましょう。

テスト/モッキング コミュニティは、通常、「スタブ」(静的で手書きのクラス) と「モック」(動的でランタイム生成のクラス) と呼ばれる、手動でローリングしているものを区別することがよくあります。

スタブだけに比べて、モッキングの利点は非常に大きいです。多くのテスターは、テストのためだけにインターフェイスの実装や具体的なクラスのサブクラスを作成するという考えに苛立っています。これを行うには、特定のメソッドをテストしたいだけの場合でも、そのクラス/インターフェースのすべてのメソッドの実装が必要になることがよくあります。

モッキングを使用すると、動作を与えたいメソッドだけを定義することで、この問題を回避できます。これは強力です。さらに、モックを使用すると、テストごとに動作を変更できます。スタブでこれを行うには、まったく新しいスタブ クラスを作成する必要があります。

構文は、モック ライブラリごとに少し異なります。他のものよりも読みやすいと感じるものもあります。私の現在のお気に入りは Mockito であるため、以前の参照ですが、時間の経過とともに進化しています。組織が現在のモッキング スイートを使用している理由と、別のものがあなたのニーズを満たすだけでなく、より読みやすいかどうかを判断する価値があるかもしれません。

うまくいけば、テスト ライターが共通の動作をテスト セットアップ メソッド (JUnit の @Before など) に取り込んでくれるので、モックの作成や共通の初期化をいたるところで見続ける必要はありません。

于 2010-08-03T21:48:29.253 に答える