This section covers managing the test cases of the test suite. A test suite may contain an arbitrary number of test cases. One test case represents one complete interaction with the PUT, from the initial message sent into the PUT to the last message received from the PUT.
BPELUnit test cases consist of specifications of interactions with the PUT. Each test case contains several partner tracks (at most one for each specified partner of the PUT). The partner tracks each contain a sequence of activities which describe the frameworks actions on behalf of the partner in the given test case. Besides the actual partners which are specified in the Partners section of the editor, one additional partner, the client of the PUT, must be specified.
The Test Cases and Tracks section looks like this:
Each test case is identified by a human-readable name. These names are displayed as root nodes in the test case and tracks tree view. A test case may have any number of partners, selected from the partners in the Partners section, and one client, which are displayed as children of the test cases in the tree.
The following screen shot shows an example of editing a test case. The selected test case is not based on another test case and is non-abstract, and non-varying (see below for an explanation).
For the users convenience, anew test case is generated with all available partners and the client as partner tracks. Mostly, you will not need to change this, however by right-clicking on a test case, you may add new partner tracks; by selecting a partner track, you can edit or remove it. Note that it is not possible to remove the client track, as each test case needs a client.
The following screenshot shows an example of adding a new partner track.
The following two sections contain more in-depth information about the test case concept of BPELUnit.
BPELUnit employs an inheritance concept for test cases. A test case may be based on another test case - creating an inheritance link between the two test cases. A test case which is based on another test case inherits activities of empty partner tracks from its parent.
A test case may also be declared abstract. In this case, the test case is not run itself, but may be used as a parent by other test cases.
One of the most basic concepts in the BPEL is a language is the FLOW, i.e., executing several sequences of activities in parallel. Testing such flows involves varying the arrival times of messages received inside the FLOW block. BPELUnit supports this with the concept of a varied test case.
A varied test case is executed multiple times. Each send activity within a varied test case may have a delay sequence, which is a list of delay times. Upon execution of the test case, the specified delay time is introduced by the BPELUnit framework.