Mule Functional Tests - totally confused

Question

We have a Mule application with 6 or seven flows with around 5 components per flow. Here is the setup. We send JMS requests to an ActiveMQ Queue. Mule listens to that. Based on content of the message we forward that to corresponding flows.

 <flow name="MyAPPAutomationFlow" doc:name="MyAPPAutomationFlow">
      <composite-source>
            <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_1" doc:name="AMQ1 Inbound Endpoint"/>
            <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_2" doc:name="AMQ2 Inbound Endpoint"/>
      </composite-source>
        <choice doc:name="Choice">
            <when expression="payload.getProcessOrder().getOrderType().toString().equals(&quot;ANC&quot;)" evaluator="groovy">
                <processor-chain>
                    <flow-ref name="ProcessOneFLow" doc:name="Go to ProcessOneFLow"/>
                </processor-chain>
            </when>
            <when....
            ...........


         </choice>
    </flow>


 <flow name="ProcessOneFLow" doc:name="ProcessOneFLow">
        <vm:inbound-endpoint exchange-pattern="one-way" path="ProcessOneFLow" responseTimeout="10000" mimeType="text/xml" doc:name="New Process Order"/>
        <component doc:name="Create A">
            <spring-object bean="createA"/>
        </component>
        <component doc:name="Create B">
            <spring-object bean="createB"/>
        </component>
        <component doc:name="Create C">
            <spring-object bean="createC"/>
        </component>
        <component doc:name="Create D">
            <spring-object bean="createD"/>
        </component>    
</flow>


 <spring:beans>

    <spring:import resource="classpath:spring/service.xml"/>
    <spring:bean id="createA" name="createA" class="my.app.components.CreateAService"/>
    <spring:bean id="createB" name="createB" class="my.app.components.CreateBService"/>
    <spring:bean id="createC"  name="createC" class="my.app.components.CreateCService"/>
    <spring:bean id="createD" name="createD" class="my.app.components.CreateDService"/>
            ......
            ......
 </spring:beans>

Now I am not sure how I can write Functional tests with them.

I went through the Functional Testing documentation in Mule website but there they have very simple tests.

Is Functional Testing not supposed to make actual backend updates using DAO or Service layers or is it just an extension of Unit tests where you mock up service layer?

I was of the idea - it can take in a request and use the inmemory Mule server to pass the request-response from one component to another in a flow. Also kindly note there is no Outbound endpoint for any of our flows as they are mostly Fire and Forget type flows and status updates are managed by the DB updates the components do.

Also why do I need to create separate mule config xml files for tests? If I am not testing the flow xml that will actually be deployed on Live what's the point of this testing? I f I am creating separate xml configs just for tests that somewhat defeats the purpose to me... Can some expert kindly elucidate a bit more and point to example tests similar to the ones we are using.

PS: the components inside Mule are dependent on external systems like webservices, databases etc. For Functional tests do we need to have those running or are we supposed to mock out those services/Db Access?

Before replying to this one, what did you think of this answer stackoverflow.com/a/13609415/387927 ? — David Dossot
Hi David. if you could kindly answer the question in this thread.. looking forward to your explanation — Soumya

David Dossot David Dossot · Accepted Answer · 2012-11-29T16:52:49

Functional testing your Mule application is no different from testing any application that relies on external resources, like databases or JMS brokers, so you need to use the same techniques you would do with a standard application.

Usually this means stubbing the resources out with in-memory implementations, like HSQLDB for databases or a transient ActiveMQ in-memory broker for JMS. For a Mule application, this implies modularizing your configuration so "live" transports are defined in a separate file, which you replace with one that contains the in-memory variants at testing time.

To validate Mule had the correct interaction with the resource, you can either read the resource directly using its Java client (for example JDBC or JMS), which is good if you want to ensure that purely non-Mule clients have no issue reading what Mule has dispatched, or use the MuleClient to read from these resources or create flows that consume these resources and pass messages to the <test:component>.

FYI These different techniques are explained and demonstrated in chapter 12 of Mule in Action, second edition.

Mule Functional Tests - totally confused

2 Answers