Автоматизация модульных тестов (junit) для разработки плагина Eclipse

Мы используем сценарии сборки PDE (см. этот вопрос) и экспортируем файлы сборки ant для наших подключаемых модулей модульного тестирования. Затем эти сценарии сборки муравьев вызываются из сценариев сборки PDE (customTargets.xml) с помощью задачи муравья «муравей». К сожалению, это работает только с JUnit3. Предполагается, что для JUnit3 должен быть JUnit4-адаптер, поэтому вы можете запускать тесты JUnit4 из тест-бегуна JUnit3.

Мы, вероятно, перейдем к чему-то вроде Maven; сценарии сборки PDE на самом деле не подходят для того, что нам нужно с ними делать.

Вот инструмент, который я могу порекомендовать, если TDD кого-то заинтересует: Infinitest

Краткое описание взято с сайта Infinitest:

What is Infinitest?

Infinitest is a continuous test runner designed to facilitate Test Driven Development. Infinitest helps you learn TDD by providing feedback as you work, and helps you master TDD by reducing your feedback cycle from minutes to mere seconds.

Whenever you change a class, Infinitest runs your tests for you. It's smart about what tests to run, and only runs the ones you need. If any errors occur, it reports them clearly and concisely. This gives you instant feedback about the semantic correctness of your code, just as modern IDE's give you instant feedback about syntax errors.

Используйте Муравей и Круиз-контроль - вы вызываете модульные тесты в сценарии Муравей, а также остальную часть своей логики сборки и можете запускать их с каждой итерацией сборки - тогда Круиз-контроль может автоматизировать ваши вызовы сборки и запускать эти тесты каждый раз.

Я только что получил тестирование JUnit, работающее как часть автономной сборки для нашего приложения RCP.

Я нашел эту статью - Автоматизация модульных тестов Eclipse PDE с использованием Ant невероятно полезной. Он предоставляет код и подход, которые помогут вам начать работу. Однако я обнаружил ряд вещей:

О коде статьи

• тестировался только один пакет (мы отделили процесс сборки от кода, используя Бакминстер)
• был только один тестовый класс.
• они оба были жестко запрограммированы в скрипт сборки

О Eclipse PDE

• uitestapplication требует другого testApplication. Использование coretestapplication - нет.
• поскольку оба эти приложения находятся в пакетах, которые зависят от SWT. Это убийца в большинстве случаев, хотя и не в том случае, если ваша сборочная машина представляет собой коробку с Windows. Я бы хотел, чтобы они были разделены на пакеты без пользовательского интерфейса.

Я обнаружил, что предоставленный код является хорошей отправной точкой, но в его реализации присутствует ряд вышеупомянутых предположений.

Обнаружив эти предположения, работа была относительно простой.

Наша новая и блестящая установка

• Бакминстер строит связки.
• target копирует пакеты с целевой платформы, org.eclipse.pde.runtime и org.eclipse.jdt.junit в "tester-eclipse-install". Это должно решить вашу проблему с Java Result 13.
• найти тестовые фрагменты, глядя на рабочее пространство
• найти хост фрагмента, просмотрев манифест
• найдите тестовые классы, просмотрев проект в рабочей области.
• зарегистрировать PDETestListener, модифицированный для обработки нескольких тестовых классов
• вызвать tester-eclipse-install с несколькими тестовыми классами.

Я также читал Автоматизация сборки и тестирования плагинов и функций, но мы не используем PDE-Build напрямую.

Глядя на ваше исключение, он говорит, что приложение coretest отсутствует. Цель муравья находится в plugins / org.eclipse.test_3.1.0 / library.xml: 10

На самом деле это проблема зависимости. У Eclipse должны быть все плагины для сборки.

Чтобы настроить его правильно, нужно посмотреть 2 файла.

1. Файл продукта
2. Файл feature.xml

Товар

Убедитесь, что файл продукта содержит все необходимые плагины.

После этого добавьте функции org.eclipse.rcp и org.eclipse.test.

... плагины выше ...

<features>
      <feature id = "mock_feature" version = "1.0.0"/>
      <feature id = "mock_feature_test" version = "1.0.0"/>
      <feature id = "org.eclipse.rcp" version = "3.2.0.v20060609m-SVDNgVrNoh-MeGG"/>
      <feature id = "org.eclipse.test" version = "3.2.0.v20060220------0842282442"/>
 </features>

Вам нужен org.eclipse.test для запуска тестов и org.eclipse.rcp для запуска eclipse для запуска тестов.

Не забудьте установить для useFeatures значение true

<product name = "mock" id = "com.example.mock" application = "com.example.mock.application" useFeatures = "true">

feature.xml

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

... другие плагины выше ...

<plugin
         id = "org.apache.ant"
         download-size = "0"
         install-size = "0"
         version = "0.0.0"/>

   <plugin
         id = "org.eclipse.core.runtime.compatibility"
         download-size = "0"
         install-size = "0"
         version = "0.0.0"
         unpack = "false"/>

Тестам нужен org.apache.ant для запуска тестов и org.eclipse.core.runtime.compatibility для запуска.

Еще одна ошибка

Убедитесь, что в вашем целевом eclipse (копии eclipse, которую вы используете для построения против), есть только 1 копия каждого плагина. Например, если в папке плагинов есть 2 версии плагинов com.ibm.icu, eclipse будет использовать более новую. Поскольку плагин сборки pde настроен на использование определенной версии, eclipse будет жаловаться, что не может найти конкретный плагин, даже если он там есть.

Некоторые мысли

Весь процесс построения затмения мог бы быть намного лучше. На самом деле я получил этот процесс в основном методом проб и ошибок. Документация устарела и немногочисленна. Сообщения об ошибках не помогают. Это только оставляет чувство беспомощности и разочарования. Будем надеяться, что этот пост поможет товарищу-программисту сэкономить время!

В качестве альтернативы Ant у меня был хороший опыт использования нового Maven + Tycho с Hudson. Tycho обеспечивает полную поддержку разработки Osgi и Eclipse на Maven. В настоящее время он интенсивно разрабатывается, но большинство необходимых мне функций работают. С вашей стороны требуется очень небольшая настройка, поскольку он может анализировать файлы MANIFEST.MF.

Если у вас есть некоторый опыт работы с Maven, начать с ним работать несложно. Хадсон немного более проблематичен из-за отсутствия поддержки Maven 3. (разрабатываемая версия Maven 3 используется Tycho)

Ссылки для старта:

• неполные пользовательские документы

Для тех, кто все еще ищет способ выполнить тесты плагинов Eclipse вне Eclipse, мне подойдет следующая команда:

java -Xms40m -Xmx1024m -XX:MaxPermSize=512m -Dorg.eclipse.swt.browser.DefaultType=mozilla -Declipse.pde.launch=true -classpath C:\eclipse\eclipse-standard-luna-M2-win32-x86_64\eclipse\plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar org.eclipse.equinox.launcher.Main -port 22 -testLoaderClass org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader -loaderpluginname org.eclipse.jdt.junit4.runtime -classNames testpackage.testClass -application org.eclipse.pde.junit.runtime.uitestapplication -data C:\temp\log.temp -dev bin -consoleLog -testpluginname PluginName

-classpath должен быть установлен на банку запуска Eclipse. Вы можете получить точную версию для вашего Eclipse из файла eclipse.ini.

-className - это имя тестового файла плагина junit.

-data установлен как временный файл.

-testpluginname - это название плагина, который вы хотите протестировать.