Единичное тестирование OSGi-Components

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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