Over a million developers have joined DZone.

MuleSoft: Functional Test Case

MUnit is a Mule application testing framework which allows us to easily build automated tests. With MUnit, we can create Mule tests by writing common Java code.

· Performance Zone

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

Once we have utilized a Java Component in Anypoint Studio, the next challenge is: How do we test it?

For testing purposes, we can use MUnit. MUnit is a Mule application testing framework which allows us to easily build automated tests. With MUnit, we can create Mule tests by writing common Java code, slightly similar to Junit. Naturally, it is more comfortable for Java developers.

To practice this, we can use any Java class in any Anypoint project. However, it is suggested to follow the example in the previous post: MuleSoft: Method Entry Point Resolver, as the Java code example in this post refers to it.

  1. Open Package Explorer, then right click on src/test/java. Choose: New >> Class.

  2. Set the Package as: com.mulesoft.training

  3. Set the Name as: MathOperationTest

  4. Set the Superclass as: org.mule.tck.junit4.FunctionalTestCase

    • Note: we can type it directly or click the Browse button

  5. Click the Finish button

A new empty Java class will be created and opened:

package com.mulesoft.training;

import org.mule.tck.junit4.FunctionalTestCase;

public class MathOperationTest extends FunctionalTestCase {

}

Our Test class must extend FunctionalTestCase, a base test case for Mule functional tests. It contains a number of supporting classes and contexts, which will make it easy to do the testing.

Before completing our Test class, the first thing that we have to do is specify the configuration file to be tested. To do that, we have to override the getConfigResources() method and then specify the file name.

package com.mulesoft.training;

import org.mule.tck.junit4.FunctionalTestCase;

public class MathOperationTest extends FunctionalTestCase {
    protected String getConfigResources() {
        return "mathoperation.xml";
    }
}

Note: we can specify more than one file using a comma-separated list.

Now we will complete our simple mathematic operation by testing the MathOperation class directly through the mathoperationFlow.

To test the Java class directly, it is not different from a common JUnit operation. Please refer to the example below, and run a JUnit test by choosing: Run As >> JUnit Test

package com.mulesoft.training;

import static org.junit.Assert.assertEquals;
import org.junit.Test;
import org.mule.tck.junit4.FunctionalTestCase;

public class MathOperationTest extends FunctionalTestCase {
    protected String getConfigResources() {
        return "mathoperation.xml";
    }

    @Test
    public void testJavaClass() {
        String value = "4";
        MathOperation mathOperation = new MathOperation();
      
        assertEquals("16.0", mathOperation.power(value));
        assertEquals("2.0", mathOperation.squareRoot(value));
    }
}

By choosing this approach we can test the specific function. If required, we can test the flow to make sure its behavior is appropriate. For this purpose, add this snippet into the current Test class:

@Test
public void testFlow() throws Exception {
    MuleEvent event = runFlow("mathoperationFlow", "4");
    MuleMessage message = event.getMessage();

    assertNotNull(message);
    assertNotNull(message.getPayload());
    assertEquals("16.0", message.getPayload());
}

Here, we utilize runFlow to call the flow by its name, and send the payload as a second argument. The behavior of the rest of the code is similar when we run Mule on debug mode. We can evaluate the message, payload, etc.

Another approach to test our integration project is testing the inbound endpoint. It simulates the real execution of the flow by using MuleClient to interact with the running Mule server. Basically, there are many options for this interaction. In this example, we specify the URL as the first argument, the payload as the second argument, and set null for message properties (it is not needed in this example) as the third argument.

@Test
public void testInboundEndpoint() throws Exception {
    MuleClient client = new MuleClient(muleContext);
    MuleMessage message = client.send("http://localhost:8081/power", "4", null);

    assertNotNull(message);
    assertNotNull(message.getPayload());
    assertEquals("16.0", message.getPayloadAsString());
}

That is how to test a Java Component in Anypoint studio. So feel free to try the different options and choose which one suits your integration project.

Happy testing!

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.

Topics:
mulesoft

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}