Table of Contents

Search

  1. Preface
  2. Welcome to Informatica Process Developer
  3. Using Guide Developer for the First Time
  4. Getting Started with Informatica Process Developer
  5. About Interfaces Service References and Local WSDL
  6. Planning Your BPEL Process
  7. Participants
  8. Implementing a BPMN Task or Event in BPEL
  9. Implementing a BPMN Gateway or Control Flow
  10. Using Variables
  11. Attachments
  12. Using Links
  13. Data Manipulation
  14. Compensation
  15. Correlation
  16. What is Correlation
  17. What is a Correlation Set
  18. Creating Message Properties and Property Aliases
  19. Adding a Correlation Set
  20. Deleting a Correlation Set
  21. Adding Correlations to an Activity
  22. Rules for Declaring and Using Correlation Sets
  23. Correlation Sets and Engine-Managed Correlation
  24. Event Handling
  25. Fault Handling
  26. Simulating and Debugging
  27. Deploying Your Processes
  28. BPEL Unit Testing
  29. Creating POJO and XQuery Custom Functions
  30. Custom Service Interactions
  31. Process Exception Management
  32. Creating Reports for Process Server and Central
  33. Business Event Processing
  34. Process Central Forms and Configuration
  35. Building a Process with a System Service
  36. Human Tasks
  37. BPEL Faults and Reports

2. Designer

2. Designer

Tips on Using Assertions

Tips on Using Assertions

A key component of the B-unit testing framework is the ability to perform assertions. An
assertion
describes the expected correctness of the state of a unit of code when it runs. Assertions include:
  • Input data for invoke activities
  • Replies from synchronous messages sent into the engine via the B-unit Send Message command
  • Values for alarm deadlines and durations
Assertions contain expected data and run against data from the process execution. The expected data for the assertion can be a text node, an element, or an imported element. The assertion can run against the entire message data or can use an XPath query to select a portion of the message data.
The B-unit engine validates messages for receives/replies/invokes. As such, it is unnecessary to do assertions on a full message. Instead, you can write assertions that focus on the portion of a message that tests logic within your process. This type of focused assertion makes your unit tests more readable and reduces the amount of work necessary if the message definitions ever change. For example, if you want to assert that the value of
rm:ProductGroupId
is
100
, the following query provides you with the most flexibility:
<abu:assertEquals part="p" query="//rm:ProductGroupId/text()">100</abu:assertEquals>
In this example, note the use of the descendant axis in the query. This selects the
ProductGroupId
element anywhere in the message. While this lack of specificity is not always a good idea, keep in mind that the B-unit engine is already validating the structure of a message so if the element were misplaced, this is reported in schema validation.
Here are some good uses of assertions:
  • Asserting the input for an invoke when that input was produced by one or more complex data mappings within the process
  • Assertion proves that a specific path was taken within the process in the case where there is conditional logic in the process in the form of transition conditions or if/else activities
It is probably not worth doing an assertion on something you would get with schema validation or with a large literal assertion when there's only a small part of the message that is worth asserting.


Updated March 30, 2020