If you're reading this you must be wondering what you have to do to increase the probability that your problem is resolved. Following is a brief discussion of what your explanation of the problem should include:
- Explain briefly what you problem is. Use point form or short paragraphs as it makes it easier to read and understand.
- Specify the Mule version, Jdk version as well as the version numbers of other technologies you are using in your application
- If the application involves any complicated routing, it will be useful to provide a diagram of your system (possibly generated using the visualizer tool available with Mule).
- Provide the relevant exception stack listing
- Provide your configuration file or at least the relevant parts of your configuration.
- Whenever possible, also provide a test case package that would illustrate your problem. Actually, this is the ideal situation since this will save other people from having to replicate your error first. We will now take a look at a problem which was actually taken from the Mule User List and illustrate how a test case can be built to illustrate the scenario depicted here.
My server should be able to send a message with attachment (eg. image) to client over soap. I expect that sending image as an attachment would be more efficient than sending it as for example a byte array. A client should be able to receive the attachment and for example display it to the user.
...and it fails when invokes receive method.
In the above scenario, the problem is evident; the Server can't send Attachments over Axis to client application. In other cases, there may be more than one problem. In such cases you should list the problems individually and test for each independently on any other errors. Once the problem is identified you should build a test case in order to test for this problem and build a scenario where the problem is replicable.
The FunctionalTestCase available in Mule not only allows you to build JUnit tests but also to define a mule configuration file (which will be used to load Mule), so extending this class for your tests is encouraged. An important factor to keep in mind when creating a test case is the level of detail. It is better to cut down to the basic stuff by removing anything from the configuration that does not directly relate to the problem. For example, in the configuration that the client provided for us above, the security filter and the transformers can be removed. As a test component we can create a class called org.foo.FileOperationsComponent that will implement a method that is very similar to the one provided to us by the user. This method, once called, will create a file, create a datahandler with that file, and send it back to the client. We must also provide an interface for this class since we're using Axis.
We build the mule configuration file for this test the same way we would build our mule configuration. Below we configure our OperationsComponent to accept an inbound message over the Axis transport:
The test case would look something like the following. Please note that the mule-config.xml file as seen above is referenced in the getConfigResources() method in the test case.
Note that there are three assertions that we are making above.
- We assert that the payload returned by the message is not null.
- We assert that attachments are being returned in the MuleMessage from the FileOperationsComponent
- We assert that the attachment returned is the correct one.
In the case of this particular problem, the test case will not meet the second two conditions and will fail thus demonstrating that there is a problem with Attachments being received from the server over Axis in a more clear-cut and concise way.