From the IBM WebSphere Developer Technical Journal.

Introduction

In Part 1 of this series on component testing, we described an approach to performing repeatable testing of Service Component Architecture (SCA) components using the JUnit open source framework and Cactus, its server-side extension, and we showed how a unit test suite for a component can be defined in a set of test specification files with optional payload files. Figure 1 shows the major test specification parts for a service that takes a simple PostCode string and returns a data object, the expected result being specified in a simple payload file.

Since Eclipse JUnit execution facilities are delivered with WebSphere Integration Developer, running a set of tests is simple. The result is a visual display, like the one shown in Figure 2.

In this article, we will describe some issues you might come across when testing SCA components that implement business processes using Business Process Execution Language (BPEL), then discuss how to address these issues by using mock objects. We will also present some techniques for creating mock objects quickly. This article is accompanied by a download file with code examples that implement these techniques.

If you plan to work through the examples presented in this second article, you will find it helpful to work through the previous article first.

Back to top

Testing BPEL

Since the WebSphere Process Server programming model exposes business processes as SCA components that can be invoked in the same manner as any other SCA component, we might then expect to be able to test BPEL SCA components in the same manner as any other component. However, we find that there are some issues with such as approach. Consider the very simple, example process shown in Figure 3.

This example demonstrates the three key problematic issues:

1. The business process uses a human task, and the result of the human task controls some key execution paths.
2. External services may not be readily executable in unit test environments; for example, they may depend upon infrastructure not available to the developers.
3. The business process is initiated but there is no corresponding reply.

Let's look at each of these issues in more detail.

1. Human task

The use of human tasks is extremely common is real world business process implementations. Clearly, if we are to implement a repeatable set of tests that can be executed automatically, then we must find a way to remove the need for human intervention. Further, our example shows a very common pattern: the outcome of the human task determines which code path is taken. In Figure 3, you can see that the choice between InvokeAgreedPayment and InvokeCaseClosed depends upon the human response.

If our tests are to achieve good code coverage, then we must be able to control the result of human tasks. Hence, the need for the following requirement:

It must be possible to simulate the actions of humans in response to different input data.

2. External services

External services present a number of challenges in addition to the previously noted one-way response issues:

• Some services (for example, those implemented using mainframe or ERP systems) may not be available to developers in unit test environments.
• Even when such systems are available, the test data may not be suitable for exercising all code paths; that is, it may be difficult to simulate some error conditions.
• In many cases, the development of services occurs in parallel with the development of business processes. Hence, there is no guarantee that a service implementation will be delivered when it is needed for unit testing.

These factors lead to another testing requirement:

It must be possible to simulate the actions of services in response to different input data.

3. One-way invocation

Until now, all our SCA tests have had the pattern invoke service, validate response. Our example business process, in common with many real world business processes, has no response. We can readily construct a unit test to invoke the BPEL process, but there is no response to validate, so how can we determine its success or failure? Our determination of success or failure must lie in the ability to determine whether actions such as invoking other services have been performed correctly.

If our example process is correctly implemented, then particular values of input data will lead to the service invocation InvokeAutoSettlement while other input values will lead to the creation of a human task and, subsequently, other service invocations.

This leads to the testing requirement:

It must be possible to determine that a service invocation has occurred.

We also note that there are assignment statements prior to the two service invocations, which may be arbitrarily complex. This leads to another requirement:

It must be possible to determine that the correct data was used to invoke a service.

There is one further requirement, this one being particularly important when the BPEL process has more complex logic. In our simple example, it's clear that if InvokeAutoSettlement is used, then (for example) InvokeAgreedPayment will not be used. A unit test should be able to determine that such mutual exclusivity has been correctly implemented. Therefore:

It must possible to determine that a service has not been invoked.

Before we consider how such testing requirements can be satisfied, let us consider some additional issues.

Back to top

Mock objects and mock object controllers

We have established the need to emulate SCA components such as human tasks and external services so that they can drive particular code paths in the BPEL process. This is accomplished with the common testing pattern known as mock objects.

Implementing such mock object services in WebSphere Integration Developer is comparatively simple. Our starting point would be a real component interface, such as that shown in Figure 4.

WebSphere Integration Developer enables us, with a few mouse clicks, to create a new SCA component that implements that interface, as shown in Figure 5.

With a further mouse-click, we can then generate a skeletal implementation of the interface:

public class MockCustomerImpl {
	// ... constructor etc. removed ...

	public DataObject getCustomer(Integer customerId)
			throws ServiceBusinessException {
		//TODO Needs to be implemented.
		return null;
	}

}

We can then complete the creation of a functioning mock object by adding code to construct, populate, and return a suitable data object. In principle, creating such code is not particularly difficult, but can be somewhat tedious and error prone to write, especially if the data object is large and contains nested objects and arrays. This is a very similar issue to that we encountered in the previous article when performing test invocations. There, we needed to construct potentially complex payload objects, and our solution was to externalise the payload data to XML files. Here, we will show how to apply the same ideas to mock object return values, externalising the return values to XML files.

With mock objects, we can replace human tasks and service components to create a reproducible test harness for our BPEL processes; we will be able to execute the processes without human intervention and with no dependency on external systems.

So, we have addressed some of the test requirements: we can actually execute the tests. The remaining issues are concerned with validating that a test was successful. To do this, we need to verify that:

• Specific services were invoked with the correct data.
• Specific services were not invoked.

We accomplish this by extending the capabilities of the mock object, adding a second interface (Figure 6).

In this interface, you see four operations. The loadData operation is used in our scheme for externalising return data, which we will discuss later. The remaining three operations resetLastRequest, checkNoRequest, and checkExpectedResult enable the validation of service invocation.

Our mock object will then implement both the service interface of the component it is replacing, plus the controller interface. An outline of a mock object implementation would look like:

public class MockServiceImpl {
	// ... constructor etc. removed ...

	private DataObject lastRequest = null

	// the service method used by the BPEL process under test
	public void exampleServiceMethod(DataObject requestData)
			throws ServiceBusinessException {
		lastRequest = requestData;
	}

	public void resetLastRequest(String label)
			throws ServiceBusinessException {

		lastRequest = null;
	}

	public String checkNoRequest()
		throws ServiceBusinessException {

		assertIsNull(lastRequest);

	}

	public String checkExpectedRequest(DataObject expectedValue)
			throws ServiceBusinessException {

		// code to compare expectedValue with lastRequest
	}
}

A test of a BPEL process that uses the exampleServiceMethod could consist of three steps, each specified in its own .tspec file:

1. Invoke the mock controller resetLastRequest.
2. Initiate the BPEL process with values intended to drive the BPEL to a path invoking exampleServiceMethod with certain values.
3. Invoke the mock controller checkExpectedRequest, passing the expected values; if the expected values are not found, an exception is raised by the mock controller and the test will fail.

Similarly, a second test sequence can be defined to verify that exampleServiceMethod was not invoked:

1. Invoke the mock controller resetLastRequest.
2. Initiate the BPEL process with values intended to drive the BPEL to a path not invoking exampleServiceMethod.
3. Invoke the mock controller checkNoRequest; if lastRequest is not null (implying that exampleServiceMethod was unexpectedly called), then an exception is raised by the mock controller and the test will fail.

The scheme we describe here is simplistic and intended to demonstrate the principles of using a mock controller interface in conjunction with a mock object. This scheme will not be sufficient for more demanding scenarios such as:

• Multi-user scenarios where many mock object instances are servicing many requests.
• A BPEL process makes several different calls to the same mock object in rapid succession.

Such scenarios expose the need for a more sophisticated scheme, than simply keeping and checking the most recent request data. In the remainder of the article, we will show how to implement our simplistic mock object scheme, exploiting a set of libraries and components that greatly reduce the work required. If your test scenarios require a more complex mock controller implementation, the structure described here will provide a good starting point.

Back to top

Test scenario

Our test scenario is part of a fictional archive application managing a long-term store of items. We will be working on the business process by which a customer requests that an item be retrieved and is later notified that the retrieval has completed.

You can download a Project Interchange file containing all the code for this example. If you want to work through this article, then import these projects:

If you open the Assembly diagram for the MP_ArchiveRetrieval module, you will see the interfaces offered by the retrieval process and services it uses.

Process interfaces

We see that the process has an initiation interface (Figure 8).

This interface might reasonably be accessed by a customer via some suitable user Interface. The process also has a second interface, by which the process is notified of the completion of a retrieval request (Figure 9).

Services used by retrieval process

The business process uses two services. The Customer service will retrieve customer information given the customer's unique ID (Figure 10).

When the retrieval is completed then the process will notify the Customer via the CustomerCommunication service (Figure 11).

Required mock objects

The projects you imported did not include implementations of the Customer and CustomerCommunication services. We will create mock objects for these two services later in this article. (If you wish to skip the work of creating the mock objects, you can import the projects MT_MockCustomer and MT_MockCustomerCommunition from the Project Interchange file.)

The retrieval process

Before we start work on the mock objects, you might like to examine the business process as it is currently implemented. Open the process to see the overall structure, shown Figure 12.

At this stage, we are primarily interested in the three items highlighted in red:

• The Receive statement labelled Initiation: this is the target of our unit test initiation.
• The Invoke statements labelled GetCustomerDetails: we will look at this in more detail shortly, but note that this is one point where a mock object will be invoked.
• The Invoke statement labelled NotifyCustomer: this is our second mock object invocation point.

You might also notice that this is far from a complete implementation of the process; for example, there is no actual access to the archive system. We show this abbreviated example for ease of understanding; however, it is worth reflecting on two points:

• Our preference is to build and test large BPEL processes incrementally, focusing on particular parts of the overall process. Our repeatable tests give us confidence should any re-factoring become necessary.
• An important principle, especially relating to performance testing, is "Test Early, Test Often." We would wish to take even a skeletal process like this example into integration test and performance test environments. Early experiments give immediate insights into stability, error handling, and performance characteristics.

You can also examine the fault handlers for the GetCustomerDetails invoke, noting that notFound faults and transientError faults are potentially treated differently (Figure 13).

In this simplified code, we have no special treatment of the different faults; however, in a real implementation, we would need to exercise these different paths. When we implement our mock object, we will need to consider how to produce the different errors needed to drive the different paths.

Back to top

The unit tests

To examine the unit tests that we intend to run, open a Web perspective in WebSphere Integration Developer. In the Project Explorer view, expand Dynamic Web Projects => MT_TestArchiveRetrievalJunitWeb => Java Resources => Java Source => com.ibm.issw.archive.utsuite => ArchiveTest-Data => testArchiveInitiation (Figure 14).

The ArchiveInitiation test is comprised of five steps. Open each tspec file in turn to understand how the test proceeds:

• 010-InitialiseCustomers resets the Customer mock object.
• 020-InitialiseNotification resets the CustomerCommunication mock object.
• 030-LoadCustomers initialises the Customer mock object with some customer data. (We will explain how this works shortly.)
• 040-InitiateRetrieval starts the business process itself. The expectation is that the process will use GetCustomerDetails to obtain data from the Customer mock object and then use the NotifyCustomer features of the CustomerCommunication mock object.
• 050-CheckNotification will then verify that the CustomerCommiunication mock object was called with the correct data.

You will also see another set of tests owned by CustomerTest.java, in the CustomerTest-Data directory (Figure 15). These tests enable us to exercise the Customer mock object directly. These are supplied to enable a quick demonstration of the mock object we are about to build next.

We will describe the purpose of these tests when we are ready to run them, after we have completed building the Customer mock object.

Back to top

Customer mock object

To create the Customer mock object, we will perform these general steps:

1. Create the mock Customer module
2. Create mock Customer component
3. Generate an implementation class
4. Implement loadData operation
5. Implement getCustomerDetails operation
6. Test the mock object

A. Create the mock Customer module

In these examples, we create separate modules for each mock object. For a realistic development scenario, this does result in the creation of a quite a number of modules and WebSphere Integration Developer projects, but we find the benefits of separation of concerns outweigh the increase in complexity.

To create the module:

1. In the Business Integration perspective, Business Integration view, right-click and select New => Module to display the New Module dialogue.

2. Enter the module name MT_MockCustomer and click Finish.

3. The mock object must implement the Customer interface from the L_Archive library. We will also exploit some libraries from our test framework. Therefore, we need to set up the necessary dependencies. Double-click on the newly created project to bring up the Dependency editor.

4. In the Libraries section, click Add to bring up the Library Selection dialogue.

5. Select L_Archive and click OK.

6. Similarly, add dependencies on J_ScaUtilities, L_ScaTest (Figure 16).

   
   
   Figure 16. Add libraries
   
   
   

   Note that mock objects do not themselves use JUnit, and therefore we do not need to add dependency on the LT_ScaJUnitTest library.

7. Use File => Save and File => Close to save your changes and close the dependency editor, respectively.

B. Create mock Customer component

8. Select the MT_MockCustomer Assembly Diagram and double-click to open the editor.

9. In the palate, select the uppermost element, and from the sub-palate, select Component (with no implementation type), then click on the editing surface. This creates the mock object component. (Figure 17)

   
   
   Figure 17. Mock Customer assembly
   
   
   

10. Right-click the newly created component. Rename the component MockCustomer. The primary role of the Mock Customer component is to provide the CustomerService interface.

11. Select Add Interface from the context menu to bring up the Add Interface dialogue.

12. Select I_CustomerService and click OK. You can see the result in the Details tab of the Properties view (Figure 18).

    
    
    Figure 18. Mock Customer with service interface
    
    
    

C. Generate an implementation class

To create a skeletal implemention of the mock Customer component:

13. Right-click on the component and select Generate Implementation to bring up the Generate Implementation dialogue.

14. This dialogue enables you to specify the Java package for the implementation class, offering names derived from the interface namespaces. It is a common convention to use package names that conform to your own naming convention. To do this, click ,b.New Package, and then enter a suitable name. We use com.ibm.issw.archive.mock.customer (Figure 19). Click OK.

    
    
    Figure 19. Implementation package
    
    
    

15. Select the newly created package and click OK again to generate the implementation code (Figure 20).

    
    
    Figure 20. Generated implementation
    
    
    

16. Now, select Add Interface again and add the I_MockServiceController interface. Notice that we have generated the service implementation before adding the second interface; we will be using a library implementation of the mock controller interface, so we don't need to write any code for the second interface.

    
    
    Figure 21. Mock object interface
    
    
    

17. You can see the result in the Details tab of the Properties view (Figure 22).

    
    
    Figure 22. Mock Customer interfaces
    
    
    

18. Two other projects, MT_TestArchiveRetrieval and M_Archive, will need to use this mock component, so export the interfaces to give those projects access. Right-click the MockCustomer component, and select Generate Export => SCA Binding to bring up the Select Interface dialogue (Figure 23).

19. Check both interfaces, then OK.

    
    
    Figure 23. Export mock Customer interfaces
    
    
    

    Your assembly diagram will now look like Figure 24.

    
    
    Figure 24. Mock Customer export
    
    
    

20. Save the Assembly Diagram. We are now ready to provide implementations for the interfaces.

D. Implement loadData operation

Now that we have added the mock Service Controller interface to the MockCustomer component, you will see an error because we have no implementation of the required operations (Figure 25).

A suitable set of implementations is provided in the testing framework, in a base class named ScaMockBase.

21. Modify the MockCustomerImpl.java implementation to extend this base class by adding the import of ScaMockBase and the extends clause as shown below:

    import com.ibm.swservices.sca.test.ScaMockBase; import com.ibm.websphere.sca.ServiceBusinessException; import commonj.sdo.DataObject; import com.ibm.websphere.sca.ServiceManager; public class MockCustomerImpl extends ScaMockBase {

    
    

22. Save these changes. This will remove the errors.

23. Examine the code for the ScaMockBase class.Click on the class name and press F3 to open the code. You will see a number of protected (and therefore accessible to your MockCustomer class) member variables:

    protected Logger m_logger = Logger.getLogger(this.getClass().getName()); protected Object m_lastRequest = null; protected String m_lastFaultName = null; protected List m_dataList = new ArrayList();

    
    

    You will see that ScaMockBase populates m_dataList with valid customers from XML files:

    DataObject data = XmlSdoUtilities.readDataFromXmlFile(dataFiles[count]); m_dataList.add(data);

    
    

    We will be using this list in our getCustomerDetails implementation. We need to create some files containing a set of valid customer data. The format of the files is the serialised form of the Customer data object:

    <?xml version="1.0" encoding="UTF-8"?> <_:TestDefinition xsi:type="l:Customer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:l="http://L_Archive" xmlns:_="http://scatest/issw/ibm/com"> <customerId>2</customerId> <name>Bingley Bradford</name> <email>bb@bbbs.com</email> <phone>22222</phone> </_:TestDefinition>

    
    

    Remember that in our previous article we described a utility for creating an example of such files from the data object definition. The data files must be located in the mock Customer project so that they can be picked up from the class loader. We have provided some sample files, delivered in the MT_TestArchiveRetrievalJUnitWeb project.

24. In the Web perspective, Project Explorer view, expand Dynamic Web Projects => MT_TestArchiveRetrievalJUnitWeb => Java Resources => JavaSource.

25. Right-click on the com.ibm.issw.archive.testData.Customer folder, and select Copy.

26. Expand Other Projects => MT_MockCustomer, then right-click com.ibm.issw.archive.mock.customer, and Paste (Figure 26).

    
    
    Figure 26. Install test data
    
    
    

    We have now placed the test data in a directory tree in the same location as the MockCustomer class; the test data is loaded by the classloader for this class. If you chose a different package name, you will need to adjust the location of the test data files accordingly.

27. You now have an implementation of the loadData operation, along with test data for it to load. Open the two data files Customer001.xml and Customer002.xml and note the Customer IDs that will be loaded.

Other attributes of the ScaMockBase class

You should notice that in ScaMockBase, an instance of java.util.Logger is created, enabling us to add trace and error statements to our implementation:

protected Logger m_logger = Logger.getLogger(this.getClass().getName());

Also, m_lastRequest and m_lastFaultName are used to implement the Last Request scheme we described earlier. We will be using these later in our second mock object implementation.

E. Implement getCustomerDetails operation

We can now return to MockCustomerImpl.java and add the implementation of getCustomerDetails.

28. Use the following code as the body of that method:

    m_logger.fine("getCustomer " + customerId); for (int i = 0; i < m_dataList.size(); i++){ DataObject candidate = (DataObject) m_dataList.get(i); int candidateId = candidate.getInt("customerId"); m_logger.finest("candidate " + candidateId); if ( candidateId == customerId.intValue()){ m_logger.finest("returning candidate "); return candidate; } } throw new ServiceBusinessException("NotFound");

    
    

    Observe that the implementation emits trace events using the m_logger member variable from the base class.

29. Save your implementation.

F. Test the mock object

You now have a functioning mock object that provides the getCustomerDetails method and a set of tests for that object. You can now deploy the MockCustomer module and the tests to a server, and then verify that the MockCustomer operates properly.

30. Wire the test module to the mock service module by expanding the MT_TestArchiveRetrievalApp module, and open its assembly diagram. You will see the standalone references used by the tests.

31. Select the customer standalone reference and, in the Properties view, select the Binding tab.

32. Click on Browse to display the SCA Export Selection dialogue. Select the export provided by the MockCustomer module. (Figure 27)

    
    
    Figure 27. Wire MockCustomer to test
    
    
    

33. In the same way, wire I_MockServiceController to the same module. We now have enabled the tests to use both interfaces to our mock object.

    
    
    Figure 28, Wire MockCustomer Controller to test
    
    
    

    Now we can deploy the modules to the server.

34. In the Business Integration perspective, Servers view, right-click the WPS server, and select Add Remove Projects to bring up the Add and Remove Projects dialogue.

35. Add MT_TestArchiveRetrievalApp and MT_MockCustomerApp to the server, then click Finish.

    
    
    Figure 29. Deploy MockCustomer for testing
    
    
    

36. Wait for the application deployment and initiation to complete and then execute the test. In the Web perspective, expand MT_TestArchiveRetrievalApp and select CustomerTest.java.

37. From the Run menu select Run... to display the Run dialogue.

38. Select JUnit and click New.

    
    
    Figure 30. Run MockCustomer test
    
    
    

    This will create a new run configuration, CustomerTest, as shown in Figure 31.

    
    
    Figure 31. Run configuration
    
    
    

39. Add the Cactus URL specification:

    -Dcactus.contextURL=http://localhost:9080/MT_TestArchiveRetrievalJunitWeb

    in the Arguments tab (adjust the host and port to correspond to your test environment).

40. Click Run to launch the test.

You should see the JUnit test succeed, plus some information displayed in the console showing the data comparisons performed by the test (Figure 33).

Take the time to study the test files. You will see:

• 01-InitialiseCustomers, which resets the list of customers held by MockCustomer.

• 02-LoadCustomers, which reads the test data we installed. Notice how the location of the test data is specified in the payload:

  <service>I_MockServiceControllerPartnerRef</service> <method>loadData</method> <payloadString>testData/Customer</payloadString>

  
  

• 03-GetCustomer, which retrieves a customer with a specified ID and compares the details with the contents of the expected results file ExpectedCustomer.xml.

• 04-GetBadCustomer, which attempts to retrieve a customer with an invalid ID and expects a specific fault to be thrown.

This test demonstrates that our MockCustomer is able to provide different responses that could drive our business process to different paths.

Back to top

Mock CustomerCommunication object

We will illustrate the second aspect of mock objects by constructing a MockCustomerCommunication object. In our business process, the CustomerCommunication component should notify the Customer about the results of its retrieval request. In testing the business process, we want to determine that the Communication component is invoked with the correct data. We will enable such testing by creating a suitable mock object.

Creating the MockCustomerCommunication component

Creating MockCustomerCommunication uses the same techniques you just followed for the MockCustomer object. We will outline the steps here, but detailing only new information; refer to the detailed instructions and screenshots above, as applicable.

1. Create an MT_MockCustomerCommunication module, adding dependencies on the L_Archive, J_ScaUtilities and L_ScaTest libraries.

2. Create MockCustomerCommunication component and implementation, following these additional steps:

   • Add the I_CustomerCommunicationService interface to the component.
   • Generate a skeletal implementation in a package com.ibm.issw.archive.mock.customercommunication.
   • Add the I_MockServiceController.
   • Generate an export for the two interfaces with an SCA binding.
   • Modify the implementation to extend the ScaMockBase class, thus implementing the I_MockServiceController interface.

3. Save your work so far. There should be no errors.

Implementing the service

We now need to consider the service operation that will be used by our business process.

4. Open your implementation class and examine the sendRetrievalResult method. Observe that there is no useful implementation.

   public void sendRetrievalResult(DataObject retrievalNotifcation) { //TODO Needs to be implemented. }

   
   

5. We require that this method interact with the ScaMockBase class so that the testing methods checkExpectedRequest and checkNoRequest can verify whether this method has been called with the correct data. Achieve this by modifying the code to read:

   public void sendRetrievalResult(DataObject retrievalNotifcation) { m_logger.info("sendRetrievalResult" + XmlSdoUtilities.getDataObjectAsXml(retrievalNotifcation)); saveLastRequest(retrievalNotifcation); }

   
   

6. The trace message exploits a utility method in the class XmlSdoUtilities, so you will need to add this import statement:

   import com.ibm.swservices.sca.utilities.XmlSdoUtilities;

7. The call to a method in ScaMockBase, namely saveLastRequest, is the only required implementation. Ensure all your changes are saved. The mock object is now complete.

Testing the BPEL process

We can now wire the BPEL process to the two mock objects we created and run the tests.

8. In the Business Integration perspective, open the MP_ArchiveRetrieval assembly diagram and select the CustomerService import.

9. In the Properties view, select the Binding tab and click Browse to bring up the SCA Export Selection dialogue.

10. Select the export from your mock Customer module and click OK.

11. Examine the values entered in the binding tab to see how they refer to your mock object module.

    
    
    Figure 35. Wire process to MockCustomer
    
    
    

12. In the same way, select the CustomerCommunicationService import and wire it to the MockCustomerCommunication module. The result should be as shown in Figure 36.

    
    
    Figure 36. Wire process to MockCustomerCommunication
    
    
    

13. Save the modified assembly diagram.

14. We also need to enable the tests to invoke the mock object controllers, so open the MT_TestArchiveRetrieval assembly diagram and use the technique described above to ensure that the imports are correctly wired as summarised here:

15. Now we are ready to initiate the test. Ensure that your test server is started and add the four projects to it:

    • MP_ArchiveRetrieval
    • MT_TestArchiveRetrieval
    • MT_MockCustomer
    • MT_MockCustomerCommunication.

16. In the Web perspective, expand MT_TestArchiveRetrieval and select ArchiveTest.java. Select Run => Run... to create a JUnit launch configuration, remembering to specify the VM argument:

    -Dcactus.contextURL=http://localhost:9080/MT_TestArchiveRetrievalJunitWeb

    
    
    Figure 37. Launch archive test
    
    
    

17. The JUnit test should complete with no errors. Examine the test specifications to remind yourself of how the tests and mock objects cooperate to verify the process behaviour.

Back to top

Conclusion

We have seen how simple mock objects can enable repeatable unit testing of a BPEL process, and described a simple framework that greatly eases the construction of mock objects. Applying the principles of repeatable unit testing to BPEL development increases both productivity and quality.

Back to top

More in this series

• Part 1: Create automated unit tests for SCA modules
• Part 3: Testing business processes that use human tasks

Back to top

Download

Information about download methods

Resources

• Service Component Architecture
  
  
• SCA application development
  
  
• Building SOA solutions with the Service Component Architecture
  
  

About the author

David Artus is member of the IBM Software Services for WebSphere team working out of the IBM Hursley Lab in the UK. He has provided WebSphere consultancy and mentoring since he joined IBM in 1999. Prior to joining IBM David worked in a variety of industries including Investment Banking, Travel and IT Consultancy. His interests include design of distributed systems, object technologies, and service-oriented architectures.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Testing BPEL
• Mock objects and mock object controllers
• Test scenario
• The unit tests
• Customer mock object
• Mock CustomerCommunication object
• Conclusion
• More in this series
• Download
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers