Once you have started testing your BPEL processes, you will be more confident that your process works as expected. But how often do you actually run the tests? Do you have an automated build system that compiles and builds your whole software (possibly including Java Web Services)? Do you have nightly builds? If one of these questions caught your attention, then you might consider the Ant task for BPELUnit.
Apache Ant is an open source build system for Java projects and is widely used in both open source and commercial development projects. It is shipped with the popular IDEs like Eclipse and Netbeans. Ant defines so called targets, i.e. goals a developer wants to have fulfilled. Typical targets are deploy and build. For each target a set of activities, so called tasks, are defined. For instance, the target build will typically call the (Java) compiler. For a more exhaustive introduction see Mills' ANT Tutorial.
Ant can be extended by custom task types. BPELUnit ships with a task for running a BPELUnit test suite. Therefore, you can integrate test runs into your build files.
An example build file for Ant that is very similar to the one that is shipped with the BPELUnit distribution looks like:
<project name="My Project Name" default="test">
<property name="BPELUNIT_HOME" value="path/to/your/bpelunit/" />
<path id="lib.path">
<fileset dir="${BPELUNIT_HOME}/lib">
<include name="*.jar" />
</fileset>
</path>
<target name="test">
<typedef name="bpelunit" classname="org.bpelunit.framework.ui.ant.BPELUnit">
<classpath refid="lib.path" />
</typedef>
<bpelunit testsuite="tests/TestSuite.bpts" bpelunitdir="${BPELUNIT_HOME}">
<output style="XML" file="out1.xml" />
</bpelunit>
</target>
</project>
You can copy and paste this to a file called build.xml. The file contains three interesting parts. The first part of interest is the <path>-element that includes all jars contained in the BPELUnit distribution. This path is used in the second part of interest, namely the <typedef>. With typedef it is possible to declare new activities. Here, the BPELUnit task is imported that is implemented in the class org.bpelunit.framework.ui.ant.BPELUnit. Finally, the activity <bpelunit> can be used. It takes two attributes: testsuite declares which test suite you want to execute and bpelunitdir points to the BPELUnit directory. Within the bpelunit task one can declare the report that is written as XML in this example.
Once you have understood the concept of Ant, you can combine such test tasks with tasks for packaging and deploying your BPEL processes. This makes building and deploying your BPEL processes very convinient and, if BPELUnit test runs are included, you can quickly spot bugs that were introduced in the last change.
The testsuite and bpelunitdir attributes as shown above are required for the <bpelunit> task. Inside of the <bpelunit> task, you may use the following two sub-elements, which may each occur multiple times:
<output style="style" file="file"? />
Each output declaration produces a report of the test run. There are two styles available: XML (meaning a rich XML format which contains all details of the test run) or PLAIN, a simpler human-readable format which does not contain the details. If the file element is not specified, the output is sent to the command line; if it is specified, the output is sent to the specified file.
<logging level="level" file="file"? />
Each logging declaration sends the BPELUnit runtime log to the specified location. You may specify a level of logging (these are log4j levels, see below) and an optional file. If the file element is not specified, the output is sent to the command line.
The possible log levels are:
In most cases, the INFO level should be sufficient.
 Webmaster
© 2004-2010 Fachgebiet Software Engineering
Impressum
|