Developing JUnit tests

You can unit test outbound and inbound processing by creating and specifying JCA contracts and operations. You then test and compare data before and after applying the tests. The EIS Simulator Adapter code sample illustrates these steps.

Outbound

The Java EE Connector Architecture (JCA) specification defines an unmanaged mode for running adapters. This means running the adapter outside of a JCA container and in process with the caller. This is the environment for developing JUnit tests.

Through a series of common client interface (CCI) and service provider interface (SPI) calls, you can force the adapter to perform an operation you want to test. First you must create instances of ManagedConnectionFactory and ResourceAdapter then set the appropriate properties in the client code.

Your adapter cannot be dependent on "live" data inside the EIS. If so, you must either return the data to a known state after every test, or create a mock implementation of the EIS API so that EIS data remains untouched.

setUp()

In the setup method for outbound, perform the following step:

Load any schemas (if necessary)

Test

When you have completed the steps for setting up the test, you are ready to call the CCI interaction and validate the result. The following procedure creates an object, retrieves it, and validates its content.

In the test method, you need to do the following things:

Note: These tasks can be delegated to helper methods

Create the data and metadata you can work with (JavaBeans, SDO, or other format).
Create a DataExchangeFactory for this data type, set the data as the bound object
Create a StructuredRecord and initialize it, with the Data Exchange Factory and the metadata
Invoke the adapter interaction.execute() using JCA CCI semantics
Inspect the result of the output, by getting the bound object of the data exchange factory of the output record.

Create a WBIRecord.
Create a business object, populate it with data, and place it in WBIRecord.
Set the appropriate verb in the business object.
Call the interaction, capturing the output.
Perform the assertion, which includes:
- Retrieving the object
- Validating the retrieved object against the original data

Inbound

In contrast to the outbound direction, inbound communication is not defined for unmanaged operation. To test the inbound capability of the adapter outside of a JCA container, you must implement some of the JCA container contracts. The following includes:

BootstrapContext – To obtain a reference to a work manager and a timer
InboundListener and MessageEndpoint – For the listener client
MessageEndpointFactory – To create endpoints
WorkManager – To create work instances
Work – To map to threads

For more details on these contracts, study the EIS Simulator Adapter samples that are shipped with WebSphere® Adapter Toolkit.

setUp()

The setUp() method for inbound is like that for outbound. You can, however, not need an outbound connection through the adapter. Accordingly, you only need to perform the following tasks:

Create an adapter instance and set its properties
Start the resource adapter.

Test

The test methods for inbound must do the following:

Prepare the data inside the EIS. In a polling adapter, this would cause the triggers to fire, populating the event table.
Create a MockEndpointFactory, and an ActivationSpecWithXid.
Call endpointActivation() on the adapter.
Wait for the event to arrive.
Assert the correctness of the data after it is sent to the endpoint.

Note: You can group your inbound and outbound tests into a single suite, and run them at once, getting instant feedback in your development environment.

For more details on the procedures described in this topic, study the EIS Simulator Adapter samples that are shipped with WebSphere Adapter Toolkit.