У меня есть проект UI Test и тестовый проект API с тем же стеком технологий (JAVA1.8, Cucumber-JVM, JUnit, Maven), и оба проекта показывают мне эту проблему. Вероятно, потому что в обоих присутствует одинаковый набор зависимостей.
Я использовал механизм повторного запуска Flaky test, используя встроенную функциональность maven-surefire-plugin <rerunFailingTestsCount>1</rerunFailingTestsCount>
. Кроме того, у меня добавлены зависимости огурца на основе <groupId>io.cucumber</groupId>
, а не <groupId>info.cukes</groupId>
. У обоих есть своя собственная версия зависимостей cucumber-java и cucumber-jvm.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<rerunFailingTestsCount>1</rerunFailingTestsCount>
</configuration>
<executions>
<execution>
<id>acceptance-test</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<forkCount>1</forkCount>
<reuseForks>true</reuseForks>
<includes>
<include>**/*Runner.class</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-spring</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-jvm</artifactId>
<version>2.4.0</version>
<type>pom</type>
</dependency>
@RunWith(Cucumber.class)
@ContextConfiguration(locations = {"file:/src/test/resources/spring-config.xml"})
@CucumberOptions(
glue = "com.test.uitest",
features = "classpath:cucumber",
tags = {"~@ignore","@ui_home"},
monochrome = true,
plugin = {"pretty", "html:target/cucumber-reports",
"json:target/cucumber-reports/cucumber.json",
"rerun:target/rerun.txt"} //Creates a text file with failed scenarios
)
public class AllTestsRunner {
}
Теперь, Aparently, мне нужен другой бегун со следующим кодом (согласно другим форумам и темам здесь, в StackOverflow)
@RunWith(Cucumber.class)
@CucumberOptions(
monochrome = true,
glue = "com.test.uitest",
features = "@target/rerun.txt", //Cucumber picks the failed scenarios from this file
format = {"pretty", "html:target/rerun-reports",
"json:target/cucumber-reports/rerun-report.json"}
)
public class FailedTestsRunner {
}
Но мне не нужен второй бегунок, так как механизм повтора отлично работает, когда наверху всего один бегун. Даже нет необходимости в файле rerun.txt, сгенерированном в 1-м раннер. Механизм встроенной сборки в плагине maven-surefire (v_2.21.0) вместе с io.cucumber v_2.4.0 работает отлично, и если какой-либо сценарий завершится неудачно во время 1-го выполнения, он автоматически запускается повторно без записи в файл rerun.txt.
В моем файле функций 5 сценариев. Если все они пройдут в 1-м заезде. Он успешно генерирует отчет с отчетом cucumber.json, показывающий все 5 сценариев.
Но, если (скажем) 2 из 5 сценариев терпят неудачу, и они выполняются автоматически в механизме повторного запуска, файл отчета cucumber.json записывает только результаты этих двух сценариев, а не все 5 сценариев. В целом сборка ПРОХОДИТ, если эти 2 сценария проходят повторный запуск, или ОТКАЗЫВАЕТСЯ, если эти 2 сценария терпят неудачу. Это правильно, но моя проблема в том, что cucumber.json перезаписывается механизмом повторного запуска.
Я пытался использовать плагин maven-cucumber-reporting
v_3.16.0, но он фактически читает сам файл cucumber.json и, следовательно, не решает мою проблему. Любая помощь будет оценена по достоинству.
В этом случае AllTestsRunner
запускается повторно до тех пор, пока не завершится счетчик, указанный в параметре rerunFailingTestsCount
, или не завершится ошибкой при последнем запуске. Так что последний забег всегда побеждает.
Плагин surefire создает собственные отчеты в папке цель. Два отчета - это AllTestsRunner.txt
, который является сводным, и TEST-AllTestsRunner.xml
содержит подробности. Оба этих отчета содержат подробную информацию обо всех запусках. Вы можете создать собственную программу для преобразования файла TEST-AllTestsRunner.xml
в желаемый json.
Существует плагин надежного отчета, который читает указанный выше xml-файл и генерирует html-отчет. Он будет создавать отчеты в папке сайта и запускаться с сайтом mvn. Может это сработает.
Единственный выход - использовать старый механизм повтора и объединить 2 файла json.
обратитесь к этому для слияния, может это поможет github.com/gfk-ba/senbot/issues/4github.com/damianszczepanik/cucumber-reporting
Да, я понимаю это. Я уже использовал этот механизм, используя <info.cukes>
для cucumber-jvm, а не <io.cucumber>
, а затем комбинируя два json. Склонен использовать этот последний io.cucumber
, поскольку он имеет встроенную поддержку механизма повторного запуска и не нуждается в классе FailedTestRunner.
Хорошая новость в том, что вы не делаете ничего плохого!
Плохая новость в том, что результаты, которые вы наблюдаете, полностью соответствуют ожиданиям. Это естественное следствие объединения различных инструментов (Surefire --> JUnit --> Cucumber
), которые иначе не знают друг друга. С точки зрения Cucumber может показаться, что повторный запуск представляет собой совершенно новое выполнение, поэтому он с радостью перезапишет старые отчеты. Только в начале цепочки можно создавать точные отчеты.
Таким образом, ваши варианты от наименьшего к наибольшему усилию и от худшего к наилучшему качеству:
Используйте отчеты, созданные Surefire.
Напишите свой собственный плагин, который добавляет результаты, а не перезаписывает их.
Обновлено: удалено предложение использовать огурец-jvm-параллельный плагин для создания отдельного модульного теста для каждого сценария. На самом деле это не сработает.
Привет, mpkorstanje, я попытался использовать cucumber-jvm-parallel-plugin
с версией 5.0.0
вместе с io.cucucmber
версией 2.4.0
, используя <parallelScheme>SCENARIO</parallelScheme>
Но проблема, которую я получаю, заключается в том, что для функции с 5 сценариями она создает 5 бегунов, каждый из этих 5 бегунов будет запускать все 5 сценариев повторно . Это ошибка или я что-то делаю не так.
Кроме того, другая проблема заключается в том, что если какой-либо из сценариев ОТКАЗЫВАЕТСЯ (из-за проблемы с кодом автоматизации), он перезапускается и снова терпит неудачу. Законные сбои, которые необходимо исправить. Но сборка скорее показывает УСПЕХ, а не неудачу. это неправильное поведение? Что ты предлагаешь.
Я слышал, как люди сообщают об этой проблеме и раньше, но каждый раз, когда я прошу mcve в виде репозитория github, она исчезает. stackoverflow.com/help/mcve
Я создал здесь проблему github.com/temyers/cucumber-jvm-parallel-plugin/issues/169
Спасибо за ответ. На самом деле содержимого
TEST-AllTestsRunner.xml
намного меньше, чем требуется для заполнения отчета по огурцу (cucumber.json). Согласноmaven-surefire-report-plugin
, моя команда + менеджер недовольны его отчетом, и они предпочитают иметь отчет огурца.