An Introduction to Business Process Testing using JProcessUnit

by Reza Shafii
06/05/2006

The automated testing of software components is widely accepted as a best practice within the software development field. BEA WebLogic Integration 8.1 Java Process Definitions (JPD) can be manually tested using the BEA WebLogic Workshop 8.1 test browser. However, this solution does not provide developers the capability of writing automated JUnit-based test cases. This article introduces the JProcessUnit API CodeShare project and demonstrates how it can be used to create well-defined, JUnit-based automated test cases for WebLogic Integration JPDs.

Why Test Java Process Definitions

Automated testing leads to the development of higher quality software applications. Such tests allow for the repeated execution and verification of different elements and facets of an application, a practice that is sure to decrease the likelihood of undetected software errors. To increase software quality, therefore, automated tests should be written for as many software components as possible. Further, the more critical the software component in question, the more important it becomes to have automated tests verifying its functionality.

Java Process Definitions abstract important business integration elements such as data transformation, trading partner integration, connectivity, and message brokering. Moreover, JPDs model and automate an organization's business processes by orchestrating the interactions of internal application components, end users, and external systems or services. This ability allows JPDs to play a key role in the development of composite applications as specified by the BEA SOA Domain Model. Given these critical functions, the automated testing of JPDs therefore plays a very important part in increasing the quality of WebLogic Integration applications.

With the benefits of creating automated tests for JPDs in mind, I'll give you a closer look at how this can be achieved by using the JProcessUnit API. Please note that this article assumes existing familiarity with the JUnit framework.

How To Test Business Processes Using JProcessUnit

As can be seen by the class diagram in Figure 1, JProcessUnit test cases are based on the JUnit framework. A JProcessUnit ProcessTestCase class extends the JUnit TestCase class. The test methods of a ProcessTestCase can initiate and interact with WebLogic Integration JPDs by using instances of ActionEvent and WaitEvent subclasses that are ultimately subclasses of the ProcessEvent class.

Figure 1. JProcessUnit class diagram

ActionEvent subclasses are used to initiate a JPD and perform tasks that a JPD instance will respond to. Examples of such tasks include creating a database entry, publishing a message to a messaging channel, or modifying a particular worklist task state.

WaitEvent subclasses are used to wait for (or verify the occurrence of) a specific result from a JPD instance. An example of such an event could be the creation of a database entry by the JPD, the arrival of a message in a messaging channel, or the creation of a particular worklist task.

Figure 2 shows how a set of ActionEvent and WaitEvent subclass instances can be used in a JProcessUnit test method to create a specific test case.

Figure 2. JProcessUnit test case interactions

With the JProcessUnit testing paradigm ProcessEvent classes are used to simulate message exchanges between JPDs and external systems (as shown in the area marked by a circled "1" in Figure 2). However, this can best be done if the integration between the JPD and the external system is implemented through a loosely coupled means such as messaging or file exchange. This is due to the fact that this type of integration usually allows us to write ProcessEvent subclasses that "act" like the target system with which the JPD is supposed to interact without much difficulty. This is done by using a WaitEvent to detect the production of the message (or file) by the JPD and an ActionEvent to create the appropriate response message in return.

If the integration between a JPD and an external system is achieved through more tightly coupled RPC based protocols, the creation of ProcessEvent subclasses that simulates the system becomes more complex. This is due to the fact that we no longer have a way of easily detecting outbound JPD calls to the target system. In such cases, the use of a test system that the JPD can interact with is an alternative (as shown in the area marked by a circled 2 on Figure 2).

Also note that during the construction of a JProcessUnit test case, we don't necessarily need to worry about the number of JPDs involved. We can instead test a business process that is started through the initiation of a particular JPD whether this involves child JPDs or not. This idea is illustrated in Figure 2 by a test case for a business process involving JPDs 1 and 2.

The analysis of this paradigm should lead to an important question: How does one make sure the server artifacts are properly cleaned up after tests are executed? For example, if a test case fails after the process has created a task, I would not want to leave the task around in a pending state and would want it removed. To take care of this problem, you can choose to use the undo feature of JProcessUnit. This feature allows you to build a list of JProcessUnit events as undo events. You can then execute the undo events, in the sequential order in which they were added, by calling the ProcessTestCase's runUndoEvent() method in the test case's tearDown() method. The undo feature allows us to create test cases that clean up after themselves.

Now that you have a better idea of how JProcessUnit events can be used to test WebLogic Integration business processes, I will briefly explore the inner working of these events. Note that detailed descriptions of the JProcessUnit events are not provided in this article; for this information you should refer to the project's API documentation.