Testability is one of the underestimated qualities of software. This is also the case for WSO2 ESB projects. However, it is important to design the integrations for testability. This starts with the way you setup the proxies. This blog gives some guidelines which you can use to design for testability.
Sequences
Sequences are a way in WSO2 to group Mediators. A proxy has by default an in-sequence, out-sequence and optionally an error-sequence. These sequences can be split-up in sub-sequences. This is a good way for reuse, but also a way to split up the design. A proxy usually contains the following functional parts:
- Validation
- Transformation
- Sending to an endpoint
These parts can be put in separate sequences. This has the advantage that the part scan be reused in other proxies. This is also the way to enable testing for these parts.
Design for testability
The sequences are the basis for the testability of WSO2 ESB proxies. The following design guidelines and steps can be used for testing your proxies.
- Configure separate testable parts within a separate sequence
A good guideline in splitting is that the parts should be as independant as possible from other parts. Good examples are: input validation, data transformation, sending a message to an endpoint, a step within an iteration. - Define a separate developer studio project for the test proxies
This will be the proxies that will contain a testable sequence and can be called from soapUI for example. This way also the test package can be deployed separately. This way the test project is not deployed on production. - Define a soapUI project for testing the component
It is wise to define a separate soapUI project for each component (WSO2 proxy) you want to test. Note that this can also be used within a Continuous Integration environment for automatic testing.
Example
The following is an example in which a data transformation is tested.
Step 1 – Define data transformation in a separate sequence
Step 2 – Define separate ESB project with test proxy
Note that the sequence is referenced and the result of the sequence is returned with respond mediator.
This result can be checked within soapUI using Asserts later on.
This result can be checked within soapUI using Asserts later on.
Step 3 – Define a soapUI project with test cases
In the request message put a soap message as expected by the sequence. Note that the ESB uses soap as its common message format within the mediation. The response can be checked with assertions.
Request
Response
Conclusion
The sequence split can be used to configure testable parts within a WSO2 ESB implementation.
This may not always be easy to do but hopefully you can use it to test your ESB implementations.
Feel free to comment on this blog! All feedback is welcome.
