0

I've been building a Mule application for a while now and have just begun experimenting with writing JUnit tests for my flows. The flows I've built typically handle flat-file transformations and are structured similar to the below:

<flow>
   <inbound endpoint>

   ... DO SOMETHING WITH THE FILE ...

   <outbound endpoint>
</flow>

My inbound/outbound endpoints are specific locations in the environments I'm deploying to and differ for each flow. The question I have is what's the best practice/approach in writing a test to inject a file into my flow and then check the output? Is it normal to create a test copy of the config file with dummy, vm endpoints and inject the file into that? Or is it more appropriate to go with a composite source like below and inject the file into the regular flow? Apologies for the potentially novice question, this is the first time I've worked with automated testing.

<flow>
   <composite source>
      <inbound endpoint>
      <vm endpoint>
   <composite source>

   ... DO SOMETHING WITH THE FILE ...

   <choice>
      <when "file originates from inbound endpoint...">
         <outbound endpoint>
      </when>
      <otherwise>
         <vm endpoint>
      </otherwise>
   </choice>
</flow>
danw
  • 1,608
  • 4
  • 29
  • 48

2 Answers2

1

Mule has its own testing framework, basically instead of marking your class as @Test (Junit4) you just extend FunctionalTestCase (which indirectly extends JUnit framework) http://www.mulesoft.org/docs/site/current/apidocs/org/mule/tck/FunctionalTestCase.html

So, to start with I would first recommend reading this page: http://www.mulesoft.org/documentation/display/current/Functional+Testing

And suppose your inbound endpoint is http then you would use something like below, please note muleClient is available for you from parent class.

    muleClient = muleContext.getClient();

    Map<String, Object> props = new HashMap<String, Object>();
    props.put("http.method", "GET");

    MuleMessage result = muleClient.send(webaddress, "", props);

    assertNotNull(result);
    assertNotNull(result.getPayloadAsString());
    assertFalse(result.getPayload() instanceof NullPayload);

And more asserts as needed.

Mujahed
  • 186
  • 1
  • 7
  • Thanks for your answer @Mujahed. I'd actually had a look through the Mule documentation and found it was limited to quite a simple test case. In my scenarios, I'll be using simple file inbound endpoints. What I was trying to understand is whether it's best to use a test that drops files in those locations (and configure a seperate connector to avoid archiving test files), or to use a different endpoint altogether in the form of a composite source? – danw May 06 '14 at 16:22
1

In your same situation, I use a properties configuration file for each environment. On that environment customized file, I define the address(including protocol) of each inbound/outbound element. For the local environment I use files and directories, and for all the other environments, I use the real protocols. That allows you to test locally without depending on the availability of any service.

Andres
  • 10,561
  • 4
  • 45
  • 63
  • Thanks @Andres. I'm picking up files from a folder structure that is mirrored on each environment I deploy to - so I've mirrored this structure locally as well. I think I'll just continue with using the same endpoints and not configuring a composite source unless somebody opposes that option. – danw May 06 '14 at 16:44
  • I think it's a good solution. However, I don't have too much experience with Mule yet. – Andres May 06 '14 at 18:33