Author: vanto
Date: Mon Dec 10 18:37:44 2012
New Revision: 1419642
URL: http://svn.apache.org/viewvc?rev=1419642&view=rev
Log:
fix formatting.
Modified:
ode/site/trunk/content/writing-bpel-test-cases.mdtext
Modified: ode/site/trunk/content/writing-bpel-test-cases.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/writing-bpel-test-cases.mdtext?rev=1419642&r1=1419641&r2=1419642&view=diff
==============================================================================
--- ode/site/trunk/content/writing-bpel-test-cases.mdtext (original)
+++ ode/site/trunk/content/writing-bpel-test-cases.mdtext Mon Dec 10 18:37:44
2012
@@ -1,5 +1,8 @@
Title: Writing BPEL Test Cases
-ODE has a test framework to automatically run BPEL processes. A big part of
our test harness is therefore many different BPEL processes that test specific
BPEL configurations or interactions. If you run into a problem with one of your
processes that seems to be a bug, the best way to get it fixed is to contribute
a test case to the project. We'll run it and keep it to prevent regressions.
The more test cases we have, the more robust ODE will be.
+
+## Overview
+
+ODE has a test framework to automatically run BPEL processes. A big part of
our test harness is therefore many different BPEL processes that test specific
BPEL configurations or interactions. If you run into a problem with one of your
processes that seems to be a bug, the best way to get it fixed is to contribute
a test case to the project. We'll run it and keep it to prevent regressions.
The more test cases we have, the more robust ODE will be.
This small guide will just explain you how to write and structure a test case
to include it in ODE's test suite. For those who rather have examples than
explanations, you can already check all [existing test
cases](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/).
@@ -16,7 +19,7 @@ Other than that your process can do anyt
<a name="WritingBPELTestCases-TestDescriptor"></a>
### Test Descriptor
-So to begin with your test process must at least have a [BPEL
file](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.bpel),
a [WSDL
file|http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.wsdl]
and the standard
[deploy.xml|http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/deploy.xml]
deployment descriptor (links are provided for the HelloWorld test case). All
of these should be included in a single directory.
+So to begin with your test process must at least have a [BPEL
file](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.bpel),
a [WSDL
file](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.wsdl)
and the standard
[deploy.xml](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/deploy.xml)
deployment descriptor (links are provided for the HelloWorld test case). All
of these should be included in a single directory.
Then for the test framework to know what it should do you will also need to
write a simple test descriptor. It's a simple properties file saying which
service is implemented by the process and which messages should be sent to
start it and make it continue. It should me named test?.properties with the '?'
being a increasing number. Here is the descriptor for the HelloWorld example,
in test1.properties:
@@ -36,22 +39,22 @@ Also if your process needs to receive se
test1.properties
-
+
namespace=http://ode/bpel/unit-test/testCorrelation.wsdl
service=testCorrelationService
operation=request
- request1=<message><requestMessageData><testMessage><requestID>Start
Test5.1</requestID><requestText>Event Start
+ request1=<message><requestMessageData><testMessage><requestID>Start
Test5.1</requestID><requestText>Event Start
Test5.1</requestText><requestEnd>no</requestEnd></testMessage></requestMessageData></message>
response1=ASYNC
-
+
test2.properties
-
+
namespace=http://ode/bpel/unit-test/testCorrelation.wsdl
service=testCorrelationService
operation=continue
- request1=<message><requestMessageData><testMessage><requestID>Start
Test5.1</requestID><requestText>Event Start
+ request1=<message><requestMessageData><testMessage><requestID>Start
Test5.1</requestID><requestText>Event Start
Test5.2.1</requestText><requestEnd>yes</requestEnd></testMessage></requestMessageData></message>
- response1=.*Event Start Test5.1 -> loop on receive until message
includes requestEnd = yes -> received
+ response1=.*Event Start Test5.1 -> loop on receive until message
includes requestEnd = yes -> received
message -> process complete.*
@@ -89,7 +92,7 @@ Practically the probe service takes 2 pa
Here is a usage example extracted from the [correlation test
case](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestCorrelation/testCorrelation.bpel):
- <receive name="receive1" partnerLink="request"
portType="wns:testCorrelationPT"
+ <receive name="receive1" partnerLink="request"
portType="wns:testCorrelationPT"
operation="request" variable="request" createInstance="yes">
<correlations>
<correlation set="testCorr1" initiate="yes"/>
@@ -109,13 +112,13 @@ Here is a usage example extracted from t
<assign>
<copy>
<from>
- <literal><![CDATA[loop on receive until message
+ <literal><![CDATA[loop on receive until message
includes requestEnd =
yes]]></literal>
</from>
<to variable="probeInput" part="probeName"/>
</copy>
</assign>
- <invoke name="probe" partnerLink="probe" portType="prb:probeMessagePT"
operation="probe"
+ <invoke name="probe" partnerLink="probe" portType="prb:probeMessagePT"
operation="probe"
inputVariable="probeInput" outputVariable="probeInput"/>
@@ -132,14 +135,14 @@ The first assign initializes the probe p
<to variable="reply" part="replyText"/>
</copy>
</assign>
- <reply name="reply" partnerLink="request" portType="wns:testCorrelationPT"
operation="continue"
+ <reply name="reply" partnerLink="request" portType="wns:testCorrelationPT"
operation="continue"
variable="reply"/>
The returned data is finally tested by using a nice regular expression for the
response:
- response1=.*Event Start Test5.1 -> loop on receive until message
includes requestEnd = yes ->
+ response1=.*Event Start Test5.1 -> loop on receive until message
includes requestEnd = yes ->
received message -> process complete.*
@@ -151,7 +154,7 @@ A complete usage example can be found wi
When invoked, the fault service (as the name says) will return a fault. It's
mostly used to test fault handlers and compensation. To invoke the fault
service just use:
- <invoke name="throwTestFault" partnerLink="fault"
portType="flt:faultMessagePT" operation="throwFault"
+ <invoke name="throwTestFault" partnerLink="fault"
portType="flt:faultMessagePT" operation="throwFault"
inputVariable="fault" outputVariable="faultResponse"/>
