OSGi functional and integration testing

[thomas.diesler]

There are currently three testsuites related to JBoss OSGi

1. Native Framework Testsuite
2. JBoss OSGi Testsuite
3. OSGi Alliance TCKs

Native Framework Testsuite

This is the testsuite that must pass at all times. It is a prerequisite for a successful Native Framework build, which is consumed by the JBoss OSGi Testsuite and the TCKs. Test coverage is low, framework dependent and only runs in an embedded scenario.

JBoss OSGi Testsuite

This testsuite is strictly framework independent. Tests are expected to run on Equinox, Felix and the Native Framework. As a result of this, tests are only permitted to use standard OSGi API and the JBoss OSGi provided test support API. This testsuite is designed to run against an embedded framework as well as against a remote framework which is deployed on one of the supported target containers. The non-trivial nature of remote OSGi testing is covered here.

The primary target container is the JBoss Application Server. Our main focus of OSGi testing is that real OSGi bundles actually work in AS. The Native Framework Testsuite is inadequate to provide that coverage as has been shown on many occasions. If it works embedded in your IDE or the Maven command line, it does not mean that it also works in AS. Putting a functional OSGi test in this testsuite also has the benefit of verifying it agains the RI framework (i.e. Equinox)

Third party componenents that need to be updated in the AS can be put into the IzPack installer. This is especially true for JBossMC snapshots that are not yet released and included in AS. A JBoss OSGi release must not overwrite any component in AS. That is because these overwrites are only verified against the OSGi testsuite and may break other areas of AS functionality.

OSGi Alliance TCKs

There is also a nighhtly build of the core and various enterprise TCKs. Commiters are not yet expected to monitor these.

The Hudson QA Environment

The JBossOSGi Hudson QA environment is an integral part of the JBoss OSGi code base. With every release we test the matrix of supported target containers and frameworks.

http://jbmuc.dyndns.org:8280/hudson

There is a wiki page that describes how to setup a local copy of the QA environment in two easy steps

----------------------

Happy testing and keep the balls blue - especially in AS.

[thomas.diesler]

Installing MC shapshots to the AS through the installer will not work any more if those snaphots would trigger additional work in OSGi unrelated modules. e.g. if you would need to change ejb3 to work with the installed snapshot

If this is the case Ales and I agreed that we can temporarily disable the AS related hudson runs until the end of week 6 in our release cycle. After that proper MC releases need to make their way into the AS so that we can wrap up all the necessary work in time for the next jbosgi release.

Continous integration against the standalone runtime is not affected and gives us the opportunity to see how the framework behaves if it is not started/stoped for every test case. A long running framework is at the end of the day what people will be using when running in AS.