Challenge

A unit test in C++ and Java is well tested and well known. ActiveVOS develops BPEL which does not behave in the same way as 3GL languages, and therefore, the same rules for unit testing do not always apply. It is still important that any code that can be unit tested should be unit tested. This document provides best practices for unit testing ActiveVOS code and ensuring that a BPEL process is well tested in ActiveVOS designer.

Description

Scope

This Best Practice does not explain the usage of the ActiveVOS provided Unit testing, but instead describes what should be tested as opposed to which tool should be used. There are times when Java (as well as other third party code) is called from an ActiveVOS process. It is assumed that third party code is unit tested in its own environment. Other testing involving third party code would be Integration testing and System testing, which are out of scope for this document.

What to Test

For any given ActiveVOS process there are a number of paths that a process can take. Ideally, each of these paths should be unit tested via process simulation before deployment, as well as via actual execution via unit tests after deployment. For each path that is tested the resulting data should match the expected data.

Happy Path

There is usually at least one happy path for every process (there may be more than one).

Conditional Patterns

Count each path in a conditional pattern as well as the Else Path.

Loops

When a process has a loop there are three possible scenarios:

1. Loop does not get executed
2. Loop is executed only once
3. Loop is executed more than once.

Receives

Receives (other than the initial receive) relate to consumers that are not the activity that instantiates the process. These include Message receives, asynchronous replies from partner services/callbacks and signals. There are three conditions for receive:

1. Valid Message is received
2. Invalid message is received
3. No Message is received (Note:  This path may not be possible to test, but the fact the path exists should be documented).

Events

When a process has an Event there are three possible scenarios:

1. Event is not received
2. One event is received
3. More than one event is received (Note:  This path may not be tested but should be documented).

Faults

Even if a process has no fault handler, at least one fault should be tested. This should cause the process to terminate. For each fault handler the code should be tested with a fault and without a fault. If a receive has more than one potential fault, each fault should be tested as well as no fault.

Transition Conditions

These are expressions placed manually on links that evaluate to true or false. Each transition condition should be tested with a logical true and a logical false.

Compensations

Each compensation path should be marked for test.

Data Setup

For each path, establish what data is needed. Usually the execution path a process takes at runtime is determined by data values in the messages being received by the process. Prepare appropriate test data messages that will cause all possible paths of execution to be tested.

Code that Cannot be Tested

There may be paths in code that are dependent on runtime behavior that cannot be mimicked in design time. Document any path that cannot be unit tested.

Summary: Unit Test Setup

• Document all Possible Paths.
• Determine How to Test
• Gather data needed to test.

Simulation

The simplest way to unit test in ActiveVOS designer is to use the process simulation feature. Paths can be tested, but changing data during simulation can save time and allow testing of situations that are difficult to mimic using the same data from start to finish.

Documentation

1. Document the test.
2. Document the Result

Documentation can either be detailed or summarized. For example:

• Process ABC. Paths 23, tested 23 paths, 23 Successful tests.
• Process DEF. Paths 20, tested 20 paths, 19 Successful tests, 1 Unexpected data.
• Process GHI paths 7, tested 6, 6 Successful, 1 Unable to test see notes.

Or the path and the request and response data can be documented for each path. This is a more detailed approach that can be taken for more complex scenarios or where there are nuances in the data or logic that might be obscured by the summary format above.

Summary Unit Testing for ActiveVOS

1. Document all Possible Paths.
2. Determine How to Test
3. Gather data needed to test.
4. Perform tests
5. Document results