2

MuleでカスタムトランスフォーマーのJunitテストケースを作成しようとしていました。しかし、テストクラスでdoTransform（）メソッドを呼び出すことができませんでした。

後で、Muleがユニットテストケースの機能を提供するMuleドキュメントを見ることに気づきました。そして、ドキュメントに従って、AbstractTransformerTestCase実装するいくつかのメソッドを持っている拡張しました。

彼らです ：

@Override
    public Transformer getTransformer() throws Exception {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public Transformer getRoundTripTransformer() throws Exception {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public Object getTestData() {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public Object getResultData() {
        // TODO Auto-generated method stub
        return null;
    }

私たちは今、次のことについて混乱しています：

  1. テストロジックはどこに記述しますか？
  2. トランスフォーマーに入力を送信する場所と方法は？
  3. 変圧器から何を返しますか？
  4. トランスフォーマーから何も返さない場合はどうなりますか（トランスフォーマーはフローの最後のエンドポイントです）？
  5. テストケースを「呼び出す」方法は？
  6. カスタム例外が予想されるテストケースを作成するにはどうすればよいですか？
  7. Eclipse内のJunitテストでは、以前はそれを宣言していまし @Test(expected = RuntimeException.class)たが、ここでラバユニットテストケースでそれを行うにはどうすればよいですか？
  8. 内部で既存の「オーバーライドされるメソッド」をどのように使用できますAbstractTransformerTestCaseか？

手伝ってください。私たちは2週間以来何をすべきか理解していません。

4

2 に答える 2

4

Mule でトランスフォーマーをテストするには、次の手順を実行します。

  • org.mule.transformer.AbstractTransformerTestCase抽象メソッドを拡張して実装します (良い例として Base64 トランスフォーマーのテストを見てください)。これは、トランスの基本をカバーしています。
  • たとえば、さまざまなペイロードやプロパティを使用するなど、カバーしたいより高度なシナリオがある場合は、テスト構成で構成するトランスフォーマーと対話org.mule.tck.junit4.FunctionalTestCaseする標準の JUnit4 メソッドを拡張および作成して、機能テスト ケースを作成します。 @Test（秒）。
于 2012-10-18T00:21:39.183 に答える
0

テストを開始するときは、テスト駆動開発などの優れたプラクティスを採用することから始めることもできます。必要になるだろう：

  • 実際のバージョンのjunit（すでに入手済み）
  • 最新のモックフレームワーク（現時点で最も柔軟なツールとしてjmockitを強くお勧めします）

あなたは必要ありません：

  • ラバからの抽象ベーステストクラス

トランスフォーマーテストを作成するときは、トランスフォーマーが適切に動作することをテストします（つまり、あるオブジェクトを別のオブジェクトに変換します）。したがって、テストケースでは、トランスフォーマーをインスタンス化し、いくつかの入力で変換メチッドをヒットし、結果に対してアサーションを実行します。ラバなしでトランスフォーマーをインスタンス化でき、トランスフォーマー中にコラボレーションを必要としない場合は、単純な単体テストがあります。

ラバ、Java EE、またはそれらをテストするために必要なサブシステムとのコラボレーションが必要な場合は、ここでモックが機能します。サービスインフラストラクチャをリギングする代わりに、モックを提供し、クラスがそれらとどのようにコラボレーションするかについての期待を定義します（クラス、ミューレン、またはJDBCドライバーをテストします）。別の奇妙な環境（android）の単体テストの例を次に示します。

/**
 * shall inject assignable views   into class
 * note that mocks are specifuied as parameters
 */
@Test
public void testSimpleInjection(@Mocked final WithInjectableViews injectable,
                                @Mocked final TextView textView,
                                @Mocked final Button button) {

    // we expect that  certain methods will be called on mocked objects
    new Expectations() {
        {
            injectable.findViewById(239);
            returns(textView);


            injectable.findViewById(555);
            returns(button);


        }
    };

    // method under test
    ViewInjector.startActivity(injectable);

    // assertions
    assertEquals(textView, Deencapsulation.getField(injectable, "asView"));
    assertEquals(button, Deencapsulation.getField(injectable, "button"));
    assertNull(Deencapsulation.getField(injectable, "notInjected"));

}

// class derived from android activity,  base class is not instantiable
// in normal java environment, only on the phone or emulator but this is not
// practicable
class WithInjectableViews extends Activity {
    // shall be injected
    @InjectView(id = 239)
    private android.view.View asView;
    @InjectView(id = 555)
    private Button button;
    // shall be left alone
    private View notInjected = null;

}
于 2012-10-17T09:07:37.687 に答える