---
title: "Testing bundles, components, resolution, and dynamics"
chapter: "11"
---

# 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.