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:

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.