Внедрение зависимостей в OSGi против тестирования - PullRequest
0 голосов
/ 23 февраля 2012

Для нового проекта я смотрю на то, что OSGi может предложить с точки зрения внедрения зависимостей, и мне нравится iPOJO (чисто на основе аннотаций, а не на основе XML).

Однако, с точки зрения тестирования, Blueprint может быть лучше, так как тогда для различных тестовых случаев (тестирование функциональности) может быть достаточно переписать конфигурацию blueprint, и сразу будет добавлена ​​другая служба.

Что вы думаете по этому поводу? Могу ли я отказаться от Blueprint на основе XML (я ненавижу XML) в пользу iPOJO, не жертвуя гибкостью в плане тестирования?

Ответы [ 2 ]

1 голос
/ 23 февраля 2012

Да. Вы можете. Я не думаю, что вы будете жертвовать чем-либо. На самом деле iPOJO является более мощным, чем проект, он поддерживает такие вещи, как «Внедрение поля», «Управление жизненным циклом службы» и «Администратор конфигурации», чего нет у Blueprint ( ссылка ).

Проект, однако, является частью Спецификации OSGi Enterprise , если это имеет значение.

Я не работал с Blueprint, а просто смотрел на его спецификацию - если вы не парень из Java-бобов, я бы остался в стороне. Кроме того, я предпочитаю iPOJO, а не DS, поскольку во многих случаях он кажется намного умнее и просто делает правильные вещи.

0 голосов
/ 24 февраля 2012

Что касается модульного тестирования iPOJO, вы можете использовать конструктор (или внедрение конструктора) для внедрения фиктивных служб и эффективного тестирования поведения вашего компонента:

Итак, два варианта:

  • либо у вас есть дополнительный конструктор для внедрения зависимостей вам нужно использовать макеты
  • или ваш компонент использует конструктор инъекция, а затем вы просто вызываете конструктор с фиктивными объектами

Если вы пытаетесь провести интеграционное тестирование, вы можете просто использовать экзамен pax и развернуть свой пакет (в дополнение к iPOJO).

...