Юнит-тестирование OSGi-компонентов

Question

В настоящее время я думаю о "Как спроектировать компонент OSGi, чтобы было легко писать тесты для него с помощью таких фреймворков, как jUnit и Mockito" .

Пересмешивать зависимости между пакетами довольно просто, поскольку OSGi усиливает DIP (принцип инверсии зависимостей) и обычно существуют методы инжектора (например, сеттер).
Но как насчет внутреннего пакета?зависимости?

Например, посмотрите на этот случай .Теперь я хочу привести его в контекст OSGi ... Изображение, которое мы хотим предоставить в качестве декларативного сервиса на платформе OSGi для любого сетевого протокола, и хотим написать модульные тесты для тестирования нижнего сетевого кода, который напрямую взаимодействует собъект сокета.

Если бы мы реорганизовали создание сокета в отдельный, но все же связывающий внутренний класс POJO (Простой старый Java-объект) , как мы должны внедрить его в реализацию протокола?

• В модульном тесте мы могли бы просто использовать метод установки, но кто будет делать это в контейнере OSGi для нас?
• Создание подкласса тестируемого класса и перезапись метода-создателя будет работать только в том случае, если тестируемый класс не объявлен как финальный.

Answer 1

Тестирование взаимодействия с контейнером OSGi, строго говоря, является интеграционным тестом.Для этого вы можете использовать Pax Exam , немного сложнее освоиться, но он работает очень хорошо (особенно если вы используете функции maven и / или karaf).

ДополнительноВы можете использовать TinyBundles , который может динамически создавать развертываемые комплекты / фрагменты из вашего теста (очень круто), чтобы макетировать другие комплекты / фрагменты для обеспечения интеграции между комплектами без создания полной среды.

Для модульного или мелкомасштабного интеграционного тестирования (т. Е. Без контейнера) тогда вы можете просто смоделировать BundleContext (или, если вы используете DS и ComponentContext), если вам это нужно.

Мне немного неясноо ваших вопросах в пунктах пули.Если есть внутренний POJO, тогда вы должны будете связать зависимости через сеттеры, в противном случае, если они будут доступны реестру службы OSGi, зависимости будут решены с помощью инфраструктуры (DS или ServiceTracker).

Также подклассычто-то, чтобы переписать метод создателя, означает, что вы больше не тестируете оригинальный класс - это запах кода - попробуйте рефакторинг его, чтобы передать код создателя как отдельный класс (конструктор или установщик), а затем этот новый код создателя (сокетсоздание) может быть протестировано независимо (без учета OSGi или даже класса протокола, где он будет использоваться).