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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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