如何为 mule 自定义转换器编写单元测试用例答案

【问题标题】：How to write Unit Test cases for mule custom transformer如何为 mule 自定义转换器编写单元测试用例
【发布时间】：2012-10-17 08:41:29
【问题描述】：

我们试图在 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;
    }

我们现在对以下事情感到困惑：

在哪里编写我们的测试逻辑？
在哪里以及如何将输入发送到 Transformer？
我们从变压器返回什么？
如果我们没有从转换器返回任何东西（转换器是流程中的最后一个端点）怎么办？
如何“调用”测试用例？
如何编写需要自定义异常的测试用例？
在 Eclipse 中的 Junit 测试中，我们曾经将其声明为 @Test(expected = RuntimeException.class)，但在 mule 单元测试用例中如何做到这一点？
我们如何在AbstractTransformerTestCase 中使用现有的“被覆盖的方法”？？

请帮助我们。自 2 周以来，我们不明白要做什么。

【问题讨论】：

标签： java junit junit4 esb mule

【解决方案1】：

要在 Mule 中测试变压器，请执行以下操作：

扩展org.mule.transformer.AbstractTransformerTestCase并实现抽象方法（look at the test for the Base64 transformer as a good example）。这涵盖了变压器的基础知识。
如果您想要涵盖更高级的场景，例如具有不同的有效负载或属性，则通过扩展 org.mule.tck.junit4.FunctionalTestCase 创建功能测试用例并创建标准 JUnit4 @Test 方法以与转换器交互（ s) 您将在测试配置中进行配置。

【讨论】：

【解决方案2】：

当您开始测试时，您不妨从采用测试驱动开发等良好实践开始。你需要：

实际版本的junit（你已经知道了）
现代模拟框架（我强烈推荐 jmockit 作为目前最灵活的工具）

你不需要：

从 mule 中抽象出基础测试类

当您编写转换器测试时，您正在测试您的转换器是否正常运行（嗯，它将一个对象转换为另一个对象） - 因此在您的测试用例中，您只需实例化您的转换器并使用一些输入点击转换方法并执行您的断言结果。如果您的转换器可以在没有 mule 的情况下实例化并且在转换时不需要协作，那么您只需进行简单的单元测试。

如果您需要与 mule、Java EE 或任何您需要测试它们的子系统协作 - 模拟就派上用场了。您只需提供模拟并定义您的类应如何与它们协作的期望，而不是在服务基础设施时进行装配（您正在测试您的类，也不是 mulen 或 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;

}

【讨论】：