We were trying to write Junit test-cases for custom transformers in Mule. But we were not able to call the doTransform() method in test class.
Later we realised seeing mule docs that Mule gives features for Unit test cases. And as per the document we have extended AbstractTransformerTestCase
which has some methods to be implemented.
they are :
@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;
}
We are now confused about following things:
@Test(expected = RuntimeException.class)
but how to do it here in mule unit test cases? AbstractTransformerTestCase
?? Please help us out. We are not understanding anything since 2 weeks what to do.
To test transformers in Mule do the following:
org.mule.transformer.AbstractTransformerTestCase
and implement the abstract methods ( look at the test for the Base64 transformer as a good example ). This covers the basics of the transformer. org.mule.tck.junit4.FunctionalTestCase
and create standard JUnit4 @Test
methods to interact with the transformer(s) you will have configured in test configuration(s). As you start with testing, you may as well start by employing good practices like test driven developemnt. You will need:
You will not need:
When you write transformer tests, you are testing that your transformer behaves properly (well, it transforms one object to another) - so in your test case you just instantiate your transformer and hit transform methids with some inputs and execute your assertions on results. In case your transformer can be instantiated without mule and does not require collaboration while tranforming, you have just plain unit test.
If you need collaboration with mule, Java EE or whatever subsystems you need to test them - here mocking comes in play. Instead of rigging up while service infrastructure you just provide mocks and define expectations how your class shall collaborate with them ( you are testing your class, nor mulen or JDBC drivers ). Here is example of unit test for another weird environment (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;
}
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.