An Introduction to Business Process Testing using JProcessUnit
Pages: 1, 2, 3

How Does It Work

Most of the existing JPD wait and action events in the JProcessUnit API implement the majority (but not all) of their functionality using the ProcessRuntimeMBean and RemoteWorklistManager JMX MBeans. In fact, aside from the ReturnProcessWaitEvent wait event, all other current JPD specific events can be thought of as providing a structured facade to the use of the above mentioned MBeans.

Looking at the events that are using the ProcessRuntimeMBean MBean first, we have: the StartProcessEvent, TerminateProcessEvent, and ProcessStateWaitEvent. Of these three events, the StartProcessEvent is the most essential, as it allows you to initiate new instances of a JPD and also is needed for the use of the other two events.

An important piece of information required for the initialization of the StartProcessEvent event is the value of the message used to start a JPD. (This message contains the data passed to a particular client response node of the JPD.) The StartProcessEvent requires this value to be the content of the SOAP body of the JPD's Web service interface. Fortunately, there is a simple way to capture the required structure: All I have to do is run the JPD's test browser (by clicking the start button in WebLogic Workshop) and navigating to the JPD's "Test SOAP" tab. The text box on this page contains a pre-populated XML example of the required SOAP body content. The StartProcessEvent uses this information to construct a proper SOAP message and invoke the target JPD's desired Web service interface.

Once a JPD has been started, the StartProcessEvent event can be used to obtain valuable information from it and any of its child JPDs. This information includes:

  • The value of internal variables
  • The status of any of the JPDs
  • The label of any of the JPDs
  • The process instance ID of any of the JPDs

The process instance ID is particularly useful as it is required by the TerminateProcessEvent and ProcessStateWaitEvent for uniquely identifying their target JPD instance.

Moving on to the events within the current API that are based on the RemoteWorklistManager MBean, I have: the CompleteTaskEvent, <<code>DeleteTaskEvent, and TaskWaitEvent. All these events use the� TaskSelector class from the WebLogic Integration API to define their target set of tasks.

This leaves the ReturnProcessWaitEvent wait event, which is used to verify the responses of a JPD through a client response node. This event is unique in that it uses an embedded Web Server (implemented using Jetty) to receive and track any return message, through a Web service callback, from JPDs started by the StartProcessEvent event.

Last, it's worth examining the WaitEvent class a little closer. This class simply calls its own waitConditionSatisfied() method intermittently. Subclasses of WaitEvent only need to override this method and perform a check on the appropriate resource (for example, whether a database entry was created, or whether a particular JPD entered a specific state). The rate at which this method is called by the WaitEvent and the number of times this is done is configurable.

With this understanding of the underlying implementation of the current JProcessUnit events in mind, now I will take a look at an example that puts them into use.

Example

The example WebLogic Integration application used to create a set of JProcessUnit test cases concerns an employee time-off request business process composed of two JPDs. Figure 3 shows the top-level JPD of this business process.

Test Case Interactions
Figure 3. Example time-off request JPD

This process obviously is fictitious and is deliberately kept simple. However, it should suffice to demonstrate many of the key concepts involved when creating JProcessUnit test cases. I will now walk through the creation of test cases for two of the execution paths of this process: one to verify the supervisor's approval of the time off request and another for her denial. Both execution paths concern cases where the HR system has deemed the request feasible.

Creating the test methods

I begin by creating my JProcessUnit test methods. Each of these methods tests a single process execution path:

/**

 * Tests the supervisor approval scenario for the time off request process

 * (ProcessTimeOffRequest.jpd and IsTimeOffFeasible.jpd).

 */

public void testApprovedExpense() {



    startTimeOffProcess(createTestTimeOffRequestXML().toString());



    assertFeasibility();



    completeTimeOffApprovalTask(true);



    verifyProcessReturn(true);

}



/**

 * Tests the supervisor denial scenario for the time off request process

 * (ProcessTimeOffRequest.jpd and IsTimeOffFeasible.jpd).

 */

public void testDeniedExpense() {



    startTimeOffProcess(createTestTimeOffRequestXML().toString());



    assertFeasibility();



    completeTimeOffApprovalTask(false);



    verifyProcessReturn(false);

}

As you can see, each test method simply calls a set of utility methods in the exact same order but with different parameter values. In fact, these utility methods perform the more complex work of executing the proper ActionEvent and WaitEvent subclasses that interact with a JPD and verify its functionality. A good way to approach the creation of a process test case is to implement a utility method for testing each node (or set of related nodes) and that is exactly what I have done here. Different test cases can then use these methods to test different execution paths of the process. The next section walks through the implementation of these utility methods.

Pages: 1, 2, 3

Next Page »