Java Reference
In-Depth Information
output="${logs.dir}/output.log"
log="${logs.dir}/cargo.log" home="${jboss.home}">
<configuration>
<property name="cargo.servlet.port" value="8080"/>
<property name="cargo.logging" value="low"/>
<deployable type="ear" file="${target.dir}/ch14-
cactified.ear"/>
</configuration>
</cargo>
</containerset>
<formatter type="plain"/>
<batchtest todir="${reports.dir}">
<fileset dir="${src.dir}/cactus/">
<include name="**/Test*.java"/>
</fileset>
</batchtest>
</cactus>
</target>
[...]
As you can see, the
cactus
task is used in connection with the
cargo
tasks (this is why
we introduced Cargo a while ago). With the one declaration in the listing, we've
defined all the necessary information to start and execute tests and stop the container.
The
warfile/earfile
parameter
B
is used to specify the name of an archive file
that we're going to deploy. This has to be the name of our cactified
WAR
/
EAR
file that
holds our test cases as well as the classes that we want to test (it's the result of the cor-
responding
cactify
task). It's also obligatory to add a
containerset
nested element
C
. In this nested element we specify a number of
cargo
tasks
D
, which will define the
containers in which to execute our tests. When we say that we specify
cargo
tasks, we
mean it—these are pure cargo tasks, and they can take any parameter that a normal
cargo
task can take: proxy, timeout, server port, and so on.
In the given
cargo
tasks we have to specify the
ID
of the containers, the configura-
tion of the containers, and the deployable (the cactified archive that contains our test
cases).
C
argo tasks can work with installed local or remote instances of a container;
you need only specify the home directory of that container. But there's more; these
tasks also let you specify the so-called
ZipURLInstaller
. In this installer you specify a
URL
to a given container archive, and Cargo will download the given container from
there, extract the container from the archive, start the container, and deploy the given
deployable. Then Cactus will execute the tests inside the container, and Cargo will
stop the container. That's a fully automated cycle, and the Cactus project comes with
several sample applications that use this automation.
Our application is done; not only this, but it's also well tested using Cactus. You
already saw how to execute your tests with Ant, so it's time to show one final way to
execute the given tests, this time using another build tool: Maven.
