Testing bundles, components, resolution, and dynamics

An OSGi test strategy has layers because plain Java correctness and runtime wiring are different claims.

Plain tests

Keep business services ordinary Java and test them without a framework. Mock or fake service contracts at the object boundary. These tests are fast and explain domain behavior.

Metadata tests

Inspect generated manifests, DS descriptors, Metatype, capabilities, and API baselines. A build should fail on unresolved package imports, accidental exports, or semantic-version violations.

Framework integration

Launch Felix or Equinox with the actual runtime closure. Verify:

bundles resolve and reach intended states;
DS components become satisfied;
configuration creates and updates instances;
services bind, unbind, and replace correctly;
HTTP endpoints appear and disappear;
stopping a provider does not corrupt consumers.

The OSGi Test project supplies JUnit 5 extensions and assertions for framework objects. Pax Exam remains common in Karaf and integration suites. bnd testing can launch resolved test runs.

Failure drills

Tests should stop a provider during work, update configuration, introduce two candidates with ranking, refresh an exported package, deny a permission where supported, exhaust a bounded dependency, and restart from persisted state.

Resolver tests

Resolve the application from clean repositories in CI. Test both the chosen closure and expected failures, so a missing capability produces a useful diagnostic.

Feynman check

A unit test proves an object. A resolver test proves declared compatibility. A framework test proves dynamic wiring. A production probe proves the deployed instance. Do not substitute one for another.