Testing applications - OSGi in Action - page 245

is it packaged correctly, does it follow the container programming model, does it use
standard API s?
You should run your tests on as many containers as possible to guard against con-
tainer-specific behavior. But keeping all these containers up to date and managing
their different settings and configurations soon becomes tiresome. The newly stan-
dardized OSG i embedding and launching API (discussed in chapter 13) helps, but it
lacks features that would make testing on OSG i much easier: automatic test wrapping,
dynamic bundle creation, and common deployment profiles. Luckily, several recently
released OSG i test tools provide all these features and more.
OSG i-enabled test tools bring other benefits because they embrace OSG i, such as
improved test modularity and management. You can use them to run a complete
range of tests from basic unit tests, through various combinations of integration tests,
all the way up to advanced management tests. You'll see a real-world example of this
later that uses one of the more popular OSG i test tools called Pax Exam to test a ser-
vice bundle in isolation, combined with client bundles, and finally with older versions
of the same service to try out a proposed upgrade scenario.
Let's begin with a brief review of the various OSG i test tools available today.

7.3.1 OSGi test tools

At the time of writing this topic, three major test tools are available for OSG i:

Open Participation Software for Java's ( OPS4J ) Pax Exam ( http://wiki.ops4j.org/
display/paxexam )

■

Spring DM 's test support ( http://static.springsource.org/osgi/docs/1.2.1/
reference/html/testing.html )

■

Dynamic Java's DA -Testing ( www.dynamicjava.org/posts/da-testing-introduction )

■

All follow the same basic approach to building and deploying tests:
1 Prepare the OSG i container.
2 Deploy the selected bundles.
3 Create a test bundle on the fly.
4 Deploy and execute the tests.
5 Shut down the container.
Each tool has its own advantages and disadvantages. The Spring DM test support obvi-
ously works best with Spring-based applications. Although you can also use it to test
non-Spring applications, doing so requires several Spring dependencies that make it
appear rather heavy. Spring DM testing also only supports JU nit 3, which means no
annotated tests. DA -Testing, on the other hand, provides its own test API , optimized
for testing service dynamics such as the race condition you saw in section 7.2.5. This
makes it hard to move existing JU nit or Test NG tests over to DA -Testing, because devel-
opers have to learn another test API , but it does make dynamic testing much easier.
Pax Exam goes to the other extreme and supports both JU nit 3 and 4, with Test NG
support in the works. Table 7.1 summarizes the differences between the tools.