Каков правильный способ создания тестов JUnit для фрагментов Eclipse?

Question

Одним из наиболее распространенных применений фрагментов eclipse является контейнер для тестовых классов JUnit. Но как писать тесты JUnit для фрагмента Eclipse, когда он играет другую, более важную роль? Например, когда у него есть определенный для платформы код.

Проблема в том, что невозможно создать фрагмент для фрагмента. И вы не можете писать тесты для хост-модуля для тестирования фрагмента, потому что он даже не компилируется, поскольку фрагмент «сливается» с хостом только во время выполнения.

Answer 1

Я не знаю об удовлетворительном решении, однако вы можете рассмотреть эти обходные пути.

Eclipse, ExtensibleAPI

Вы можете использовать заголовок манифеста Eclipse-ExtensibleAPI как этого

Eclipse-ExtensibleAPI: true 

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

Это не так близко, как фрагменты теста, где вы получаете преимущества от тестов и производственного кода, используя тот же загрузчик классов, который предоставляет доступ к типам и методам, приватным к упаковке. Но вы можете, по крайней мере, протестировать общедоступные средства.

Обратите внимание, что этот заголовок является расширением Eclipse, а не частью спецификации OSGi. Следовательно, вы привязаны к Equinox, OSGi-реализации Eclipse. Кроме того, пакеты фрагмента будут экспортироваться через узел хоста и будут отображаться не только для тестового пакета, но и для всех пакетов.

библиотека Java

Если фрагмент имеет несколько зависимостей и не требует выполнения OSGi/Eclipse, вы могли бы рассмотреть вопрос о лечении его в качестве простых тестов библиотека w.r.t Java. Другой Java-проект sibling может содержать тесты и иметь зависимость от проекта (Свойства> Путь сборки Java> Проекты) в проекте фрагмента. Опять же, доступ к частным частям пакета не будет работать.

И если вы используете инструмент построения, такой как Maven/Tycho, потребуется дополнительная работа для объявления зависимостей и выполнения этих тестов во время сборки.

Bndtools

Вы также можете посмотреть в Bndtools, чтобы увидеть, если этот инструмент развития соответствует вашим потребностям лучше, чем Eclipse, Plug-in Development Environment (PDE).

Простые тесты JUnit проводятся в отдельной исходной папке в том же проекте, что и производственный код. Это даст вашему тестовому коду доступ к производственному коду так же, как если бы использовались фрагменты теста.

Bndtools также поддерживает выполнение интеграционных тестов, хотя я сомневаюсь, что у вас будет доступ к фрагментному коду, отличному от служб или другого API, предоставляемых фрагментом.

Для проектов CI, проекты Bndtools обычно используют Maven или Gradle с помощью соответствующего bnd (http://bnd.bndtools.org/) плагина. Так же, как Maven/Tycho используется для создания и упаковки проектов PDE.

Поскольку Bndtools является расширением IDE для разработки пакетов OSGi, он не знает о особенностях плагина Eclipse, таких как расширения, объявленные в plugin.xml. Следовательно, для этих артефактов нет редактора и редактора. Но если вам повезет, вы даже можете использовать конструктор PDE для отображения маркеров ошибок для недопустимых расширений и точек расширения.

Еще один недостаток, который имеет производственный и тестовый код в том же проекте, заключается в том, что чистые тестовые зависимости, такие как JUnit, макетные библиотеки и т. Д., Также видны для производственного кода во время разработки.

Конечно, выпущенные (фрагментные) пучки не содержат тестового кода и тестовых зависимостей.

Однако сам Bndtools разработан с использованием Bndtools. Таким образом, есть доказательство того, что Bndtools можно использовать для написания плагинов Eclipse.