Пакеты OSGi могут быть собраны вместе в работающем движке OSGi (будь то Equinox, Felix, dmServer и т. Д.). Как и в случае с другим кодом, могут существовать зависимости от поведения платформы (например, кода, работающего только в Windows, использующего ссылки на файлы в стиле c: \), кода, который работает вместе с JNI и действительного только для платформ x86, и так далее. В этих случаях OSGi не помогает и не мешает тестированию программного обеспечения.
Где это может добавить сложность - в явном комбинаторном взрыве бегущих пучков. В отличие от Java-приложения, которое вполне может работать на одном монолитном CLASSPATH, вы, как правило, не обнаруживает ошибок до позднего времени (например, ClassNotFoundException при попытке загрузить драйвер JDBC, например). OSGi несколько помогает в этом отношении, обеспечивая, по крайней мере, необходимый экспорт пакетов для пакетов; но даже в этом случае некоторые пакеты могут быть необязательными и, следовательно, заканчиваться той же проблемой.
Как пакет OSGi, вам действительно нужно протестировать:
- Действительно ли все эти пакеты запускаются, т.е. после установки в ваш любимый движок OSGi, работает ли n правильно? Если у вас есть все ваши зависимости, то он должен перейти от INSTALLED к RESOLVED к ACTIVE; если он остается в INSTALLED, значит, ему не хватает некоторых зависимостей
- При запуске виртуальной машины OSGi вашему приложению нужны определенные пакеты (например, декларативные или удаленные службы)?
- Есть ли проблемы с порядком запуска между пакетами? Все они должны просто работать, но вы можете проверить, что произойдет, если Пакет А запускается до Пакета В
Это те дополнительные вещи, на которые вы должны обратить внимание при тестировании при сертификации набора пакетов для работы друг с другом. В идеале, у вас должны быть тесты виртуальных машин в OSGi, которые вы можете запустить - вот как выполняются тесты плагинов Eclipse для JUnit.