Testing with Oracle BPEL - part 3

Introduction
When you create a new BPEL process from JDeveloper, you always have an empty Test Suites folder in the Integration Content folder. This is where will be all the tests.

Basic concepts :

• test suite contains several tests (I recommend to have different test suite for each kind of tests you could have)
• baseline is a common base for different tests. Each test can import a baseline to get a global behaviour (the create instance inbound message for example)

A simple process
Let's create a very simple sync BPEL process (it just copies 'OK' into the output variable). This process is called SimpleTest (source code available here).



A simple test for a simple process
Now we have our BPEL process, we want to test if our process replies 'OK' or not.
So just create a new test suite and then a new test.
You should have a new designer/source window opened. This is the test editor.
From there, you can emulate messages (inbound and outbound), add some asserts, etc.

We only want to check if our simple process replies 'OK'.

1. Emulate the inbound message
In each test, you must emulate the first inbound message (ie on the create instance invoke). This is a very common use for a baseline. Double click on the invoke activity > Emulate tab> Emulate message and then enter the content of the message.

2. Add assert activities
Then we are able to add assert activities on each BPEL activity which manipulates / transfers some variables (assign, invoke, receive, scope). Double click on our assign > Asserts tab > Create > Value Assert :

• browse the output variable and select the result element
• Comparaison method : String (this is the type of your element)
• Expected value : OK
• Error message : process is corrupted
  
• Fatal : uncheck the box ! (This is really important. If not and if the test failed, you cannot get the results. The box is checked by default)

You should have something like that (the emulation on the receive, and the assert on the assign) :



3. Deploy the test
The BPEL process must be already deployed in order to realize this step.
In the deploy menu in JDev, you have the BPEL Process Deployer but also the BPEL Test Deployer. Select this test deployer, and check the test suite, your test and your BPEL server domain. And just deploy it.



4. Running the test
The simplest way to run the test is throught the BPEL console.
In all of the tabs that you have (manage, initiate, descriptor, WSDL, etc.) when you click on a BPEL process (not a BPEL instance), you also have the testsuites tab which is usefull to run tests & test suites. Just go in this tab and check your test suite with your test.



And execute tests !

5. Reporting
You now have a complete report of the state (passed or failed) of all your tests inside your different test suites.
I particulary like the % of process coverage by the unit tests (like a cobertura report). To get a 100%, you must cover all the different paths in your BPEL process by tests (including catchs, onAlarms, etc.).
You can even see the flow of the run BPEL testing instance.


You can modify your BPEL process and have a 'KO' instead of the 'OK'. You'll need to reploy your tests as well. You should get something like that :



Source code of tests here.

Happy new year !

Testing with Oracle BPEL - part 2

The writing of BPEL tests is done in JDeveloper, in a window which is similar to the BPEL process design. The tests are not coded with BPEL language and are not a standard as BPEL.

The testing language
The test design can be done by the designer or directly by writing XML tags, which is not really convenient, but there are some testing functionnalities not supported by the designer. That's why I will explain the main tags and attributes and their functions right now.

XMLtags & attributs	Function/ Description
<BPELTest>	Document root
<initiate @operation>	Specify the behaviour of the test process instanciationreferencing a WSDL operation
<include>	Include some other test (like a baseline)
<inboundMessage>	Specify the incoming message
<emulate>	Specify the activity is emulatedNotice : The <initiate> is always emulated
<activityDriver @activity>	Do an action on an BPEL activity
<assertXML @variable,@part,@method>	Assert the content of a XML variableaccording the method used (identical, similar)
<assertActivityExecuted @activity>	Assert the number an activity is executed
<assertValue @var,@part,@method>	Assert the content of a value variable (regexp, exactmatching)
<triggerOnMessage @onMessageName>	Allow to emulate an incoming message on onMessageactivity (pick or onMessage)
<triggerOnAlarm @onAlarmName>	Allow to emulate and trigger onAlarm activity

The above list is not complete, but it contains the main tags you will deal with.

Here is the hierachy in these tags :


If you want to have a overview of all the tags, you can consult the XML schema of the BPEL test language ($BPEL_HOME/bpel/system/xmllib/InstanceDriver.xsd)

With all this stuff, we'll able to do :

• assert tests
• XML variables asserts
• values variables asserts
• execution number asserts

• emulation tests
• incoming messages
• invoke/receive/reply emulations (synchronous and asynchronous)
• fault messages
• on alarm triggers

Okay, next time, we'll do our first BPEL test.

Testing with Oracle BPEL - part 1

One of the biggest challenge with the BPEL language is the unit testing.
How can I be sure that my tiny change in my BPEL process won't affect the global behaviour of my entire process ?

Test Driven Development
In test-driven development technique aka TDD, everything is based on tests. We create first the test, check if the new test fails when we run it, then write some code, and then check if the test succeed. In Java/J2EE, this technique is very powerfull and is used in extrem programming methodology.

Testing with Oracle BPEL
I recently find out Oracle BPEL provides a test framework (actually I knew it, but I never tried it because I wasn't very confident...).
This framework will enable us to use an approach very similar to TDD. In JDeveloper, we'll have our process design as usual and others windows with our tests design.

These next features are available :

• emulate inbound and outbound messages (synch and asynch processes)
  
• assert some values and XML data
• assert the number of execution of an activity
  

With these functionnalities, we are now able to do :

• lots of unit tests on our BPEL processes
• integration tests

As in JUnit concept, all the tests can be unified in a test suite to run all tests together.
All the tests will be packaged with the BPEL suitcase.