Недавно я представил небольшой помощник для оценки точки расширения Eclipse . Вспомогательное устройство стремится уменьшить стандартный код для общих шагов программирования, одновременно увеличивая руководство по разработке и удобочитаемость.
Этот пост является обещанным продолжением, показывающим, как объединить утилиту с пользовательским утверждением AssertJ для написания облегченных интеграционных тестов для расширений Eclipse.
Затмение Расширения
Слабое сцепление в Eclipse частично достигается механизмом точек расширения и расширений. При этом расширение служит вкладом в конкретную точку расширения. Однако декларативный характер расширений и точек расширения иногда приводит к проблемам, которые трудно отследить.
Это может быть в случае, если объявление расширения было случайно удалено, конструктор по умолчанию исполняемого расширения был расширен параметрами, plugin.xml не был добавлен в build.properties или тому подобное.
В зависимости от настроек ошибок / предупреждений PDE, о многих из этих проблем следует информировать маркеры, но почему-то снова и снова случается, что вклады не распознаются, а ценное время теряется при отслеживании ошибок.
Из-за этого может быть полезно иметь облегченные интеграционные тесты для проверки того, что определенный вклад действительно доступен.
Для получения общей информации о том, как расширить Eclipse с помощью механизма точек расширения, вы можете обратиться к Руководству по среде разработки плагинов онлайн-документации.
Интеграционные тесты с подключаемыми тестами JUnit
Учитывая определение точки расширения в последнем посте …
… вклад расширения может выглядеть следующим образом:
|
1
2
3
4
5
6
7
|
<extension point="com.codeaffine.post.contribution"> <contribution id="myContribution" class="com.codeaffine.post.MyContribution"> </contribution> </extension> |
Предполагая, что у нас есть тестовый фрагмент, как описано в разделе « Тестирование подключаемых модулей с фрагментами» , мы могли бы ввести PDETest, чтобы проверить, что указанное выше расширение с заданным идентификатором существует и может быть создано с помощью конструктора по умолчанию. Этот тест использует RegistryAdapter представленный в предыдущем посте, и специальный настраиваемый assert, называемый ExtensionAssert :
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
public class MyContributionPDETest { @Test public void testExtension() { Extension actual = new RegistryAdapter() .readExtension( "com.codeaffine.post.contribution" ) .thatMatches( attribute( "id", "myContribution" ) ) .process(); assertThat( actual ) .hasAttributeValue( "class", MyContribution.class.getName() ) .isInstantiable( Runnable.class ); }} |
Как описано в предыдущем посте, RegistryAdapter#readExtension(String) считывает ровно одно расширение для данного атрибута ‘id’. Если он обнаружит более одного вклада с этим атрибутом, будет сгенерировано исключение.
ExtensionAssert#assertThat(Extension) (используется через статический импорт) предоставляет пользовательский assertJ AssertJ, который предоставляет некоторые общие проверки для вкладов расширения. В этом примере проверяется, что значение атрибута ‘class’ соответствует полному имени типа реализации вклада, что исполняемое расширение фактически реализуемо с помощью конструктора по умолчанию и что экземпляр можно назначить для Runnable .
Где его взять?
Для тех, кто хочет проверить это, есть репозиторий P2, который содержит функции com.codeaffine.eclipse.core.runtime и com.codeaffine.eclipse.core.runtime.test.util, обеспечивающие RegistryAdapter и ExtensionAssert . Хранилище находится по адресу:
и исходный код и трекер ошибок размещены по адресу:
Хотя документация полностью отсутствует в данный момент, должно быть довольно легко начать с приведенными объяснениями этого и предыдущего поста. Но имейте в виду, что функции находятся в очень раннем состоянии и, вероятно, претерпят некоторые изменения API. В частности, утверждения о вложенных расширениях пока кажутся слишком слабыми.
В случае, если у вас есть идеи по улучшению или вы нашли какие-то ошибки, средство отслеживания проблем, вероятно, является лучшим местом для решения этой проблемы , для всего остального не стесняйтесь использовать раздел комментариев ниже.
| Ссылка: | Облегченные интеграционные тесты для расширений Eclipse от нашего партнера JCG Фрэнка Аппеля в блоге Code Affine . |