Reading Time: 4 minutes

I wanted to write about a little project I have been working on which I added to the Mule testing framework recently: dynamic port testing.  As long as I have been working on the Mule ESB project, we have had weird random intermittent test failures which fail with a message like this:

Caused by: org.mule.transport.ConnectException: Failed to bind to uri 
at org.mule.transport.tcp.TcpMessageReceiver.doConnect(TcpMessageReceiver.java:81)
at org.mule.transport.http.HttpMessageReceiver.doConnect(HttpMessageReceiver.java:83)
at org.mule.transport.AbstractConnectable$3.doWork(AbstractConnectable.java:238)
at org.mule.retry.policies.AbstractPolicyTemplate.execute(AbstractPolicyTemplate.java:67)
... 50 more
Caused by: java.

.net

BindException: Address already in use
latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Most of the time, the condition is not reproducible and re-running the test again would pass.  After a lot of investigation/poking around, I traced the cause of the problem to be the OS not releasing the port quickly enough for the next test to use it.  This usually happened when the build machine was under high load.  That’s where dynamic port testing comes in.  Using variable substitution in our Mule test configuration files, I wrote a wrapper test framework class which looks for and assigns free ports to tests so we can avoid the ‘Address already in use’ condition.

If you are writing functional test cases for Mule ESB and would like to use dynamic ports, you simply need to do the following:

  1. Extend DynamicPortTestCase instead of FunctionalTestCase and implement: protected int getNumPortsToFind(){}.
  2. Use variables for the test ports in your Mule test configuration file, i.e. ${port1}, ${port2}, etc.
  3. Update the port references in your test case to either get the Mule endpoints by name or the collection of dynamic ports.

You can read all of the details here.  If you see something in the Mule ESB test framework that needs improvement, please feel free to post to the mailing list.  These are some of the things on my list:

  • JUnit4 support
  • Automated examples testing
  • Splitting unit/functional testing, or at least give you the ability to run each individually