2016/08/23

Introduction

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 and 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 and 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.

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 todo but hopefully you can use
it to test your ESB implementations.
Feel free to comment on this blog ! All feedback is welcome