Test Automation of Mule Flows with Java Components and JDBC End Points

In software engineering, testing plays an important role. The cost of finding bugs in the initial stages of lifecycle is much less than to find and fix them in the later stages.

Therefore, it is very important to find any bugs in the initial stages than to leave it to find them during integration/UAT testing.

Doing manual testing while developing is a time taking process and there are high chances of missing several test cases. Hence it is important to automate the tests while developing the software itself.

In this blog, I will explain  how we can automate testing of

• Mule flows with Java components
• Mule flows with JDBC end points

Example Use case

Flow with http inbound end point receives product id as part of http request. After http end point, there is a Java component named ProductComponent, followed by JDBC end point.

ProductComponent functionality is to call a web service to get product details for the product id and transform type of the product into a String. If the type is “1” product type is transformed to “Andriod”, if the type is “2” it is transformed to “Windows”.  This component returns a map of product details as key, value pairs.

JDBC end point inserts product details into database table.

Mule Flow and Configuration – Which can’t be automated for testing: Example Flow To be Automated

Mule Flow Config

Java component before modifications for testability. ProductStoreService is tightly coupled with Business logic. 

Automation of Unit testing of Java components and JDBC End Points

If we want to automate the testing of mule flows, it is necessary that we do automation of unit testing for java components in that flow.

While developing Java components, we should design the components for test-ability. For example, if the Java component has any dependency on any external component, say a web service, it is good practice to declare that dependency object as class variable and inject the dependency at run time. It helps in injecting mock implementations of dependencies at run time, enabling automation of testing.

In the example above, ProductComponent testing can’t be automated because it has dependency on external web service “ProductStoreService”. We need to have “ProductStoreService” up and running whenever we want to test this component or test this flow.

Also, JDBC end point data source is defined as MySQL data source. In this case, in order to test this we always have to connect to running instance of MySQL database. It may be difficult to make these tests automated especially in continuous integration.

Mule Flow and Configuration – Which can be automated for testing:Modified Example Mule Flow

Modified Config with Bean definition 

Testable Java component 

Changes made to make the flow testable (for Java Components):

• Make “ProductStoreService” as global variable and auto wire it using @Autowired annotation
• Define Product component as spring bean
• Spring beans definition can be given at run time like below

-DspringBeansLocation=classpath:testspringBeans.xml

• Spring Beans definition in production

• Spring bean definition for test cases

Where “MockProductStoreService” is the mock implementation of product store service which can be part of test cases package. In this way, we don’t need to depend on running web service and we can automate tests without external service running.

Changes made to make the flow testable (for JDBC end point):

• Datasource properties are parameterized. For testing we can use in memory database like HSQLDB.
• Data base properties for production

• Data base properties for testing

•  It is also helpful to add vm inbound end point to that the flow can be triggered from functional test case easily.

Benefits of Doing this

Designing the flows in the above way helps in enabling test automation of the flows which will add the value to the product in the following ways:

• Identify all potential bugs in the initial stages
• Continuous integration process becomes more efficient. We can test our flows on daily basis ( or even more frequently based on CI configuration ) to make sure that we are not introducing bugs while developing
• As the tests are automated, whenever someone adds a new piece of code, it is easy to test the existing functionality is not impacted because of the new changes. Thus regression testing is automated
• Automation of tests reduces the effort in testing phase as most of the issues would have been found and fixed in development because of test automation

AUTHOR: Vinay Kumar Thota has done his Masters in Mechanical Engineering from Indian Institute Of Science, Bangalore. He has 15 years of experience in Software Engineering with Architecture, Design and Development of Enterprise Applications using Java EE Technologies. He has got good exposure in Search Technologies, Messaging Platforms, Application Servers and High Available and Scalable platforms in Telecom and Mobility domains. He has got good experience in designing and developing Integration platforms using Mule ESB. He loves his parents, wife and kids (kannayya and chaitu) and tries to spend most of his time with them when not at work.

If you would like to find out more about how MuleSoft could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com

Other useful links:

Anypoint Microsoft Azure Connector Developed by Coforge

The Anypoint Asana Connector developed by Coforge

The Anypoint Expedia Connector Developed by Coforge