ESB applications and Continuous Integration

Question

I have used Junit and CI for purely Java based application which works great. Junit is used to unit tests cases for an operation/method by passing its input values( parameter) and expect the return values should match the criteria. Usually we tests the junit for a pure java based application which is having Controller, Service and DAO layer. Sometime use mock objects to mock/proxy third party applications.

Now, I have ESB application built on Mule, it is having http connectors, api kit with raml, scheduler, cloud connect to sfdc, ActiveMQ, smtp, JDBC connection to multiple DB, datampaper, datewave and continues..

Finally, Mule application is an xml file with Java/Groovy and some other technologies integrated. Java components are only 10%( or sometime none) of the application built components.

I am planning for Continuous Integration with Jenkins. For this I need to run Junit framework to do regression test of the application. I hope Munit will not work with CI since Munit has to be executed with Studio and it is written in xml file.

Since application built is not complete Java based application( in which we can write unit tests-assert for operations and its returning values) issues observed:

1. Writing Junit for Mule components are taking lot of time than writing functionality since code length is more to get the Mule xml components and have mock components.
2. I cannot have 100% code coverage for Mule ESB application. I can cobertura or other tools in Java/Junit based application for code coverage.
3. Instead of spending time on this unit tests developer can utilize time for more stable application by doing manual tests.

Moreover, an ESB applications are built to run different process to integrate together. Is it good architectural suggestions to use CI with Junit for ESB based applications? Or build, do manual tests and deploy application in server without CI and Junit tests?

Answer 1

You seem to be presenting a number of concerns about implementing Continuous Integration for Mule ESB applications. I'll try to state and answer each of your concerns below. If I haven't understood something, please update the question and I'll revise the answer accordingly.

Is my CI process limited to junit based tests alone, or can I also use MUnit tests?

You can include both MUnit based tests and junit based tests in your CI process if you use maven to automate your build. To run MUnit tests, add the following plugin to your POM:

<plugin>
  <groupId>com.mulesoft.munit.tools</groupId>
  <artifactId>munit-maven-plugin</artifactId>
  <version>1.0.0</version>
  <executions>
    <execution>
      <id>test</id>
      <phase>test</phase>
      <goals>
        <goal>test</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Should I expect to spend more time and effort writing tests for a Mule application than I do for a pure java application?

I'll answer for two categories of tests that I recommend writing for Mule applications.

1. Functional Tests
   • Format: JUnit with FunctionalTestCase
   • Learning Curve: months
   • Time required for beginner: much more than pure java
   • Time required with experience: similar to pure java
2. Unit Tests
   • Format: MUnit
   • Learning Curve: days
   • Time required for beginner: a little more than pure java
   • Time required with experience: similar to pure java

First, and I think most important, are functional tests. These should be coarse-grained, black-box, and isolated. These are written with JUnit, and are based on the Mule TCK and the FunctionalTestCase base class. Proficiency at developing these tests seems to take a while, and experience doing it on several different applications. Once you get the hang of it, and build up a set of supporting java libraries that you like, I'd expect these to take about as long as the equivalent in "pure java".

Unit tests are mostly written using MUnit, and test flows or sub-flows with specific input messages. These seem to take about the same proportion of my development time as using junit for "pure java". The learning curve is fairly quick too: I'd expect a few days for a java developer using TDD who has a decent understanding of Mule development.

Is there any way to measure code coverage of my Mule application's test suite?

I haven't seen any way to measure coverage in your CI process. However, Anypoint Studio can measure coverage at development time.

Given the time required to write automated tests, and the lack of design time reuse, would it be smarter to spend time manually testing instead of creating an automated test suite and implementing a CI process?

No. I have implemented continuous integration with automated testing on many Mule development projects and on half a dozen teams, who did not all respond with 100% enthusiastic adoption. :) The additional development time you spend in your first few projects is quickly forgotten while the benefits remain for the life of the software.

Answer 2

Mule ESB is completely based on Java/Spring. If you setup your project as a maven project with the proper dependancies then you can run munit tests outside of Studio.

It is actually covered in the Advanced Training Course. https://training.mulesoft.com/instructor-led-training/advanced-development-online-37