Testing applications - OSGi in Action - page 256

You per form an in-place update to preserve the existing configuration data in the
bundle's persistent data area (see section 3.3.4). This works only when you're upgrad-
ing bundles to a new version. If you wanted to switch to a Configuration Admin Ser-
vice implementation from another vendor, you'd need both bundles installed while
you copied the configuration data between them.
Third, you make sure the Configuration Admin Service bundle was successfully
updated to the new version before finally checking that the configuration data still
exists:
headers = cmBundle.getHeaders();
TestCase.assertEquals("org.apache.felix.configadmin",
headers.get(Constants.BUNDLE_SYMBOLICNAME));
TestCase.assertEquals("1.2.7.SNAPSHOT",
headers.get(Constants.BUNDLE_VERSION));
You can run this management test with a single command from the chapter07/
testing- example/ directory:
$ ant test.management
[junit] Running org.apache.felix.cm.integration.mgmt.ConfigAdminUpgradeTest
...
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.344 sec
You can even extend the upgrade test to make sure it works on other OSG i frameworks,
as you did with the original Apache Felix Configuration Admin Service integration tests.
You'll see that the test passes on all three frameworks, which is more proof that this ser-
vice implementation is truly independent of the underlying OSG i framework.
This was only a small test; but if you look at the management examples from chap-
ters 3 and 10, we hope you can see that you can easily script larger, more complex sce-
narios in Java (or any other JVM language) by using the standard OSG i lifecycle and
deployment API s. Imagine building up a modular library of management actions
(install, start, stop, upgrade, and downgrade) that you can quickly tie together to test
a particular task. Such management testing can help squash potential problems well
in advance, minimizing real-world downtime.
Earlier in this chapter, we showed you how to test an application all the way up
from individual classes to single bundles and combinations of bundles. Just now, we
looked at testing different management strategies, such as upgrading and downgrad-
ing components, to make sure the application as a whole (and not just this release)
continues to behave over its lifetime. At this point, you should be ready to move on to
system and acceptance tests. These tests don't need special treatment regarding OSG i,
because OSG i is just an implementation detail. As long as the application can be
launched, it can be tested.