LINUX.ORG.RU

[maven] JUnit и TestNG в один проход

 


0

1

В проекте используются тесты на основе TestNG, JUnit 3 и JUnit4.
TestNG может интегрироваться только с JUnit 3.
Наши тулзы могут интегрироваться только с JUnit 4.

Хочется, чтобы всё это работало одновременно.

Если Maven Surefire Plugin обнаруживает в parent pom конфиг, похожий на конфиг TestNG, то он для всего проекта все тесты интерпретирует как TestNG, то есть желание не выполняется.

Если попытаться вручную выставить провайдера (указанием зависимости на surefire-testng или surefire-junit47), то Surefire Plugin просто игнорирует это. То есть желание опять же не выполняется.

Есть такой хак: можно в тех артефактах, которые используют junit4, в execution properties писать testNgArtifactName=none:none. Тогда SurefirePlugin не может разрезолвить зависимость от TestNG и откатывается к ближайшему дефолтному провайдеру, то есть к JUnit. То есть, можно не указывать в parent pom никаких параметров и доопределить настройки в подмодулях.

И всё бы хорошо, но в случае использования этого хака, мы натыкаемся на следующий баг: если у нас есть два подмодуля, в одном из которых провайдер — JUnit, а в другом — TestNG, все properties, которые различаются между этими провайдерами (например, сверхважная пропертя SuiteXmlFiles) — игнорируются. То есть, тесты как бы работают, но управлять ими нельзя, и смысла в них в таком виде никакого (у меня они тупо начинают все падать по race conditions).

То есть единственный рабочий способ — использование профилей. Один проход сборки — c JUnit, второй проход сборки — c TestNG.

А это стрёмно, очень стрёмно. Во-первых, это в 2 раза увеличивает время исполнения на сервере Continuous Integration. Во-вторых, на CI нужно все эти профили создавать, причем на каждый чих. В-третьих результаты неудобно анализировать. В-четвертых, сами профили зверски неудобны.

Можно ли эту проблему решить как-то по-другому?

★★★★☆

Сколько тестов? Если в пределах 500, то специально обученный человек справится с рефакторингом за один рабочий день.

Имхо, JUnit4 или TestNG, разница не очень существенна, но для проекта надо выбирать что-то одно.

baverman ★★★
()
Ответ на: комментарий от baverman

Разница между ними существенная. Я думаю наиболее разумным подходом будет переделать все тесты на последний TestNG, на сколько бы это ни было сложно.

dizza ★★★★★
()
Ответ на: комментарий от baverman

Речь идет не о TDD, а об интеграционном тестировании. Тут несколько иная ситуация.

1. Разные тулзы генерят различные тесты. Например, мы тыкаем кнопки в веб-приложении, а специально обученная тулза делает из этих кликов пачки тестов на JUnit4. А другая тулза из текстовых файлов (а-ля rspec) генерит пачки тестов на TestNG. Потом всё это автоматически сшивается в пакеты интеграционных тестов и прогоняется Мавеном. Переписывать тулзы, чтобы они генерили консистентные тесты - не вариант, тем более что часть из них - с закрытым кодом (и кода у нас нет, только блобы).

2. TestNG лучше, чем JUnit. Дай мне волю, я бы все написал на нем, но нельзя. Конкретно, чем: параллельным выполнением тестов (с регулируемым уровнем параллелизма), в т.ч. из-под мавена, зависимостями между тестами (chaining), описанием тестов в XML (и этот XML можно генерить в зависимости от разных условий).

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от maxcom

задана.

Не знаю, чего игнорируется. Баг, наверное.

Писать testNgArtifactName=none:none придумал не я, а кто-то в интернетах, так что такой баг есть как минимум у нескольких человек.

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Если интеграционное тестирование, то напаривается связка surefire для юнит тестов и failsafe для интеграционных

maxcom ★★★★★
()
Ответ на: комментарий от maxcom

Опа, опа!
Можно будет повесить JUnit на surefire, а TestNG на failsafe, или наоборот. И повесить на разные фазы, на integration и pre-integration. Или вообще, у failsafe этого бага не будет.

Крутая идея, спасибо!
Попробую.. завтра, может быть, об результатах отпишусь.

(галку «решено» пока не ставлю, вдруг ктонить еще чего-нибудь полезного напишет, про surefire)

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от jreznot

> Хорошая идея разложить тесты в разные артефакты/модули

проблема с Surefire Plugin как раз в том, что ему неважно, по каким подмодулям разложены тесты. Если в одном из подмодулей используется TestNG, то весь билд будет билдаться через TestNG, или билдаться правильными провайдерами, но с косяками

stevejobs ★★★★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.