• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date May 25, 2021 |


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.



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.


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 (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).


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).


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.


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.


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.


  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.






Could not Run








System Test Needed














Unexpected Data

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.



Input List

Output List











xxx.xml, yyy.xml…

www.xml, zzz.xml…

This is the Happy path








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

Table of Contents


Link Copied to Clipboard