0

したがって、テスト対象のクラスには、このように勇敢に見えるコードがあります

public void doSomething(int param)
{
    Report report = new Report()
    ...do some calculations
    report.someMethod(someData)
}

私の意図は、レポートの構成を保護されたメソッドに抽出し、それをオーバーライドしてモックオブジェクトを使用し、それをテストして、someMethodが正しいデータで呼び出されたことを確認することでした。

ここまでは順調ですね。しかし、Reportは私の管理下にはなく、さらに悪いことに、実行時にJNIを使​​用してライブラリをロードします。

レポートレポートを実行する場合=EasyMock.createMock（Report.class）

次に、EasyMockはリフレクションを使用してクラスメンバーを見つけようとしますが、これによりJNIライブラリをロードしようとして失敗します（JNIライブラリはUNIXでのみ使用可能です）。

2つのことを検討しています。a）2つの実装を備えたReportWrapperインターフェイスを導入します。1つは実際のレポート（基本的にはプロキシ）への呼び出しを委任し、もう1つは基本的にモックオブジェクトを使用します。またはb）someMethodを呼び出す代わりに、保護されたメソッドを呼び出します。これにより、テストサブクラスでオーバーライドできるsomeMethodが呼び出されます。

いずれにせよ、それは厄介なようです。より良い方法はありますか？

4

2 に答える 2

0

EasyMock を使用すると、なんらかの形のリファクタリングに頼る必要があります。これを回避する唯一の方法は、内部で作成されたオブジェクトをモックできるモック ツールを使用することです。JMockit (私が開発したツール) を使用すると、テストは次のように記述できます。

public void testDoSomething(final Report mockedReport)
{
    // create "someData"

    objectUnderTest.doSomething(123);

    new Verifications() {{ mockedReport.someMethod(someData); }};
}
于 2011-02-15T12:10:22.220 に答える
0

クラスへのインターフェースがない場合Reportは、提案されたラッパーが正しいアプローチです。「リファクタリング: 既存コードの設計を改善する」
という本には、不適切に設計されたクラスからのインターフェイスの抽出に関する章があります。

何らかの DI フレームワーク (SpringFramework など) を使用している場合、このオブジェクトをいくつかのオブジェクトに簡単に置き換えてObjectFactory、正しい実装 (モックと実際の実装) を作成できます。

于 2010-12-24T10:49:09.757 に答える