Миграция тестов Спока 1.3 в Спок 2.0

Узнайте, что вы можете ожидать от Spock 2.0 M1 (на основе JUnit 5), как перейти на него в Gradle и Maven и почему важно сообщать об обнаруженных проблемах :).

Важное замечание Я определенно не советую вам перенести ваш реальный проект на Spock 2.0 M1 навсегда! Это первая (предварительная) версия 2.x с незавершенным API, предназначенная для сбора отзывов пользователей, связанных с внутренней миграцией Spock на JUnit Platform.

Это сообщение в блоге возникло, чтобы попытаться побудить вас выполнить тестовую миграцию ваших проектов на Spock 2.0, посмотреть, что начало давать сбой, исправить это (если это вызвано вашими тестами) или сообщить об этом (если это регрессия в самом Spock). В результате — на стороне Спока — будет возможно улучшить кодовую базу до Milestone 2. Выгода — помимо вклада в проект FOSS 🙂 — будет осознание необходимых изменений (хранится в стороне ветка) и готовность к миграции, как только Spock 2.0 станет более зрелым.

Я планирую обновить этот блог, когда появятся следующие версии Spock 2.

Работает на платформе JUnit

Основным изменением в Spock 2.0 M1 является переход на JUnit 5 (точнее говоря, для выполнения тестов с JUnit Platform 1.5, частью JUnit 5 вместо API-интерфейса для запуска JUnit 4). Это очень удобно, поскольку тесты Spock должны автоматически распознаваться и выполняться везде, где поддерживается платформа JUnit (IDE, инструменты сборки, инструменты качества и т. Д.). Кроме того, функции, предоставляемые самой платформой (например, параллельное выполнение теста), должны (в конечном итоге) быть доступны и для Спока.

Чтобы перенести Spock 2 в проект Gradle, необходимо повысить версию Spock:

и активировать выполнение тестов платформой JUnit:

С Maven, с другой стороны, все еще требуется переключиться на версию никогда не Спок:

но это все. Плагин Surefire (если вы используете версию 3.0.0+) выполняет тесты JUnit Platform по умолчанию, если обнаружен junit-platform-engine (транзитивная зависимость Spock 2).

Минимальный рабочий проект для Gradle i Maven доступен на GitHub .

Другие изменения

Имея такое большое изменение, как миграция на платформу JUnit, количество других изменений в Spock 2.0 M1 ограничено, чтобы немного легче найти причину потенциальных регрессий. В качестве побочных эффектов самой миграции требуется версия Java 8.

Кроме того, все параметризованные тесты (наконец) «развертываются» автоматически. Это здорово, однако, в настоящее время нет способа « накатить » конкретные тесты, как известно из spock-global-unroll для Spock 1.x.

Некоторые другие изменения (например, временно отключенный SpockReportingExtension ) можно найти в примечаниях к выпуску .

Ожидается, что в Milestone 2 будут включены более (возможно, серьезные) изменения.

Проблема с правилами JUnit 4

Ожидается, что тесты с использованием JUnit 4 @Rule s (или @ClassRule s) не пройдут с сообщением об ошибке, указывающим на то, что запрошенные объекты не были созданы / инициализированы до теста (например, NullPointerException или IllegalStateException: the temporary folder has not yet been created ) или не были проверены / очищены после этого (например, мягкие утверждения от AssertJ). API правил больше не поддерживается платформой JUnit. Однако, чтобы упростить миграцию ( @TemporaryFolder , вероятно, очень часто используется в интеграционных тестах на основе Spock), существует специальный spock-junit4 который внутренне оборачивает правила JUnit 4 в расширения Spock и выполняет их в жизненном цикле Spock. Поскольку он реализован как глобальное расширение, единственное, что требуется добавить, — это еще одна зависимость. В Gradle:

или в мавене:

Это облегчает миграцию, но стоит подумать о переходе на собственный аналог Spock, если он доступен / выполним.

Другие проблемы и ограничения

Spock 2.0 M1 скомпилирован и протестирован только с Groovy 2.5.8. Начиная с M1, выполнение с Groovy 3.0 в настоящее время блокируется во время выполнения. К сожалению, вместо четкого сообщения об ошибке несовместимой версии Groovy есть только очень загадочное сообщение об ошибке:

Это уже сообщается и должно быть усилено M2.

К сожалению, ограничение только Groovy 2.5 уменьшает потенциальную обратную связь от людей, экспериментирующих с Groovy 3, который довольно близок к стабильной версии (RC2 по состоянию на 2019/2020). Это особенно неудобно, так как многие тесты Спока работают только с Groovy 3 (конечно, есть несколько угловых случаев). Существует вероятность того, что Спок 2 до получения финала будет адаптирован к изменениям в Groovy 3 или, по крайней мере, вышеупомянутое жесткое ограничение будет снято. В то же время необходимо протестировать поддержку Groovy 3 с версией моментального снимка — 2.0-groovy-2.5-SNAPSHOT (для которой эта проверка отключена).

Резюме

Действие после прочтения этого поста простое. Попробуйте временно поиграть со Spock 2.0 M1 в своих проектах и сообщать о любых замеченных проблемах, чтобы сделать Spock 2.0 еще лучше :).