How it works

BPELUnit is a real-life testing framework, which means that the BPEL processes to be tested are actually executed inside a BPEL runtime engine, like for example the Oracle BPEL server. BPELUnit is independent from any concrete BPEL server, as it only uses standard Web service calls in conversation with the BPEL process.

To test a BPEL process in this way, both the client and all partners of the BPEL process are simulated by the BPELUnit framework, i.e., the tester specifies which data the client and partners should expect from the BPEL process, and send back in. BPELUnit comes with a sophisticated XML-based specification language which allows the tester to specify this protocol.

BPELUnit allows:

• Specification of both synchronous and asynchronous call to and from the BPEL process under test; BPELUnit includes a WS-Addressing implementation to create client- and server-side callbacks.
• Specification of data in literal XML (not SOAP Envelopes), support for document/literal and rpc/literal encoding with the possibility to add other encodings via an extension point.
• XPath-expression based verification of incoming messages, similar to assert calls in JUnit.
• The ability to send faults to the BPEL process to trigger error and compensation handling.
• Data copy/mapping routines, allowing correlation between messages.

The tester specifies a harness around the Process Under Test (PUT), which forces it down a certain path from all sides:

Note that not all partners need to be simulated; in some cases, it is even sufficient to simply simulate the client. In this case, BPELUnit acts as a black box Web service testing tool. Selection of which partners are to be simulated is done by editing the partner WSDL files, in particular, the location of the partner Web service, and of course providing instructions what the simulated partners should do in a test case. To simulate a partner, simply change the target URL in the WSDL of the Web service to a framework URL (by default, something like http://localhost:7777/ws/partername).

The test itself is specified in the Test Suite Specification (.bpts) files. An editor for these files (the tool support) is provided, based on Eclipse. Once the test specification has been written, the test may be executed. During execution, SOAP messages are exchanged via HTTP between the framework (simulating the client), the BPEL process (PUT), and again the framework (this time, simulating the partners), looking something like this:

If all messages are received and sent as expected and all checks passed, the test case completes successfully. In any other case, it is aborted, and the information shown to the user, which can go from the top level right down to the SOAP messages if needed to find out what went wrong.