Middleware Integration Testing With JUnit, Maven and VMware: Part 3
Join the DZone community and get the full member experience.Join For Free
last year, before the christmas holidays , i described how we do middleware integration testing at xebialabs and i described the way we deploy test servlets by wrapping them in war and ear files that get generated on the fly . there is only one thing left to explain; how do we integrate these tests into a continuous build using maven and vmware?
running the middleware integration tests
so let's start with the maven configuration. as i mentioned in the
first blog of this series, the integration tests are recognizable by
the fact that the classnames end in itest. that means they won't get picked up by the
default configuration of the maven surefire plugin
and that is fortunate because we don't always want to run these tests.
firstly they require a very specific test setup (the application server
configurations should be in an expected state, see below) and secondly
they can take a long time to complete and that would get in the way of
the quick turnaround we want from commit builds in our continuous
but when we do want to run the middleware integration tests, we can configure the maven surefire plugin with a maven build profile like so:
to run the middleware integration tests in addition to the regular tests, we can tell maven to use this profile with the -p flag:
$ mvn -pitest test
if we want this profile to run only the middleware integration tests, we need to leave out the lines that include the standard classnames (test*.java, *test.java and *testcase.java).
defining the expected state for the target middleware
a big challenge when performing middleware integration tests is to ensure that the middleware we test against is in a correct state. for example, the test might expect an application server cluster to be running but no application to be deployed on it. in a regular test we may set up a test fixture in a method marked with @before , but in this case that might not be so simple. confuguring the middleware to be in the expected state would be an integration in itself!
the first approach to address this issue is to write all middleware integration tests in such a way that they revert any changes they make. for example, a test that creates a datasource also removes it. in this way we combine the test for the creation-step with the test for the destruction-step. the disadvantage here is that these two steps can no longer be tested independently, but the advantage is that the combined test runs more quickly. for this approach to be successful, all tests using the same target middleware should agree on a common expected state. we configure the target middleware in that state once and all the tests return the middleware to that state after completion. with a setup like this we can quickly run one or more integration tests, either interactively from an ide such as eclipse, or from maven.
but there is one problem with this. what if the test fails? in that case the middleware might not be left in the correct state. one could argue that the steps needed to revert the middleware should be placed in an @after method but they may still fail. more importantly, those steps are also part of the test so they don't really belong there!
reverting the target middleware to the expected state with vmware
this is where vmware comes in. by installing the target middleware in a hypervisor such as vmware, we can make a snapshot when the middleware is in the expected state. then we can revert to that state before executing a single test or a test suite. the simplest thing is to manually revert from the hypervisor administration console before running the tests. but we can also revert the images automatically, so that we can integrate these tests into our continuous integration builds.
the images we use for our middleware integration tests run on vmware vsphere 4 and we've found the vsphere sdk for perl , and most specifically the provided vmrun.pl sample script, to be the easiest way to interface with vmware vsphere. as an example, this is the script we use to revert our jboss image:
image_name="[datastore1] jboss-42/centos 5.3, jboss 4.2.3-ga.vmx"
snapshot_name="ready for itest"
echo "reverting vmware image $image_name to snapshot $snapshot_name"
$vmrun -host $vmware_host -username $vmware_username -password $vmware_password \
reverttosnapshot "$image_name" "$snapshot_name"
echo "waiting $settle_time seconds for things to settle"
we do need to provide the proper values for the environment variables vmware_host, vmware_username and vmware_password when running this script. after the image has been reverted we wait for 60 seconds to allow the image to settle. the amount of seconds needed here is hard to determine exactly but this value works well for us.
to have maven run this script before the integration tests are executed, but only when a certain profile is selected, we have added this configuration to the pom:
<!-- we really want this to execute right before the test phase. -->
<!-- this is the best we can do. -->
putting it together
with the two profiles introduced in this blog, we tell maven to revert the vmware images and execute all middleware integration tests by giving the following command:
$ mvn -prevert-vmware-images -pitest clean test
we have configured our continuous integration system to run this command once a day, as a secondary build , and configured it with the right values for the vmware_host, vmware_username and vmware_password environment variables. in this way the middleware integration tests do not slow down the standard commit build (they take about 90 minutes to complete in our case!). as an added benefit, we know when the vmware images will be used by the tests so we can use them for manual experiments at other times.
in this blog and the first two blogs of this series i have explained how we use junit , maven and vmware to write repeatable, manageable middleware integration tests. these tests have helped us gain a lot of confidence in the stability of deployit 's middleware integrations. and because this test-support code is part of deployit's plugin api, deployit plugin developers can use it to get the same confidence in their own code!
Opinions expressed by DZone contributors are their own.