SOPERA Blog

Testing SOPERA-Intalio Add-On

In the last blog we shared with you our intention of combining SOA and BPM using SOPERA ASF and Intalio|BPM as the basis for an integration project. We now have some news about our approach to testing the SOPERA-Intalio add-on.

How we did testing
Previously, this is how we did testing; all our test cases were written, version-controlled, and deployed in our continuous build integration system (Cruise Control). For each possible Intalio|BPM scenario, one corresponding JUnit-based test was written. Each JUnit test case prepared test data and sent it to a specific Intalio process which in turn called up a SOPERA process. After that the JUnit testcase made an assertion on the Intalio response. Everything was then augmented with an automated Intalio/Intalio-SOPERA Add-On installation and process deployment so that we had a clean test-fixture each time.

What is new
After the initial implementation we realized that the only added value of JUnit in this case is assertion and test data setup, and as JUnit tests are sometimes hard to write and especially hard to maintain, we decided instead to simply use the full power of BPMN to move all our integration tests to a BPMN-only environment. We created a simple schema for process requests and responses where the request is left empty and the required response only requires a single boolean result.

We created a simple JUnit testcase which uses Apache ODE interfaces to discover processes and then one-by-one, verifies the response. For example, in the following picture you can see the integration test that tests the One-Way SOPERA call:

One-Way Integration Test

It is not easy to verify that the one-way service call was successful, so the BPMN Process above executes a one-way call (createLending) and then checks that the created service state is subsequently modified (by checking lending from the seekBook results).

All that the tester has to do now is:

1. Set up the BPM test environment.
2. Check out and modify the default test sets in the version control system.
3. Check it in, tag it, so that a new build is automatically created in cruise control: this starts the testing process.
4. Check the test results in Cruise Control.

That’s it!

Why we decided to take this approach

The following are the benefits we hope to achieve with this new approach:

1. All our development team members have the option of designing and testing a BPM process. We believe that using what we create is vital for successful product development.
2. Each of test cases created by a team member can be executed by any team member.
3. BPMN diagrams are much easier to understand and maintain.
4. It simulates the real user environment so that a form of in-house user acceptance testing is at play.
5. With the powerful BPMS Console from Intalio server we are presented with a perfect post-mortem examination process for our test cases and results. Since all our integration tests are BPMN processes we could investigate them step-by-step and find the reason for test failures.

Renat Zubairov Development BPM, SOA, SOPERA-Intalio, Testing