Testing a WebSphere Commerce service with a unit test case

After you apply the WebSphere Commerce service module pattern, a MyServiceModule-UnitTest project is created as a place to put JUnit tests for the created services. JUnit is a simple and commonly used Java testing framework for unit tests. For more information about JUnit, see http://www.junit.org.


Before beginning


Task info

Within the generated unit test project, a single test class is created. This test case extends from the JUnit TestCase class and contains test methods for every service that the service module supports. These test methods build empty service request objects and use the generated client library class to send the web service request and receive the service response.

The purpose of these generated test methods is to help validate the deployment of the generated pattern assets. By running the test class without any modifications of the existing service logic, the test case should send and receive empty service messages. When the test runs successfully, this unit test validates the deployment of the generated projects. The only precondition before you run the unit test is that you generate the Service Data Objects, which we must do to compile the generated pattern assets.

Each unit test project contains a sample configuration to communicate with the service module remotely or locally. By default, the configuration used by the test case is a web service in a J2SE environment, on the same machine where the test case is run. In the same directory, there is another sample configuration for demonstrating the deployment configuration to local communication and web service communication using the generated JAX-RPC mapping code.

The main goal of unit testing is to individually test the service messages to ensure that the request is processed as designed. Unit tests should test only particular service request messages and do not need to test a functional flow of messages. Test cases should be created to test individual service requests.

For unit testing, a CallbackHandler implementation is created where the user identity and password can be specified so the service is invoked under that identity. This CallbackHandler can be found in the Foundation-Samples.jar in the WebSphere Commerce project. This JAR file is only part of the development environment and is only intended for unit test purposes. The class is com.ibm.commerce.foundation.client.samples.security.auth.callback.SampleCallbackHandlerImpl. The constructor accepts the user ID and password of the identity under which to run the service.

In production, create a CallbackHandler implementation that supports your application authentication mechanism. Alternately, we can use the generated web services proxy binding.


Procedure

  1. Open the MyServiceModule-UnitTests project.

  2. Inside the project is a template JUnit test case class. Edit this class to create new test methods to unit test the component facade implementation.

  3. Optional: For extra validation when testing services, we can use the TCP/IP Monitor within WebSphere Commerce Developer. We can use the TCP/IP Monitor to monitor the SOAP messages that are exchanged between the unit test and the component facade implementation.


Example

For a tutorial that includes an example of how to test a WebSphere Commerce service module with both a JUnit test case and the TCP/IP Monitor in WebSphere Commerce Developer, see ../../tutorials/concepts/cwvstoresoitree.htm.


Related concepts
Service Data Objects (SDO)
Client library for WebSphere Commerce services


Related tasks
Creating a WebSphere Commerce service module
Generating code from an SDO genmodel file