Продолжая серию публикаций о возможностях Allure-framework, сегодня мы поговорим о работе с кодом. Под катом разбираем, что такое шаг теста, как выводить информацию в отчет при выполнении шагов и какие бывают категории дефектов. Кроме того, расскажем об аннотациях Allure. Дальше еще интереснее!
Для визуализации процессов, протекающих в ваших тестах, необходимо использовать шаги. Шаг должен представлять какое-то атомарное действие или проверку. Собственно последовательность шагов и представляет ваш тест. Для наглядности в шаге должны быть описаны входные параметры, а также ожидаемый и фактический результат, если шаг представляет собой проверку.
В Allure для обозначения тестового шага над методом необходимо проставить аннотацию @Step. Затем необходимые шаги-методы включаются в тело тестового метода: тесты с аннотацией @Test.
Рассмотрим пример
Создадим метод с аннотацией @Step, который проверяет соответствие суммы двух слагаемых ожидаемому результату:
Теперь создадим тестовый метод, использующий данный шаг:
При прогоне данного автотеста мы получим следующий отчет:
Аннотация @Step умеет принимать параметр «value», который позволяет указывать имя шага на русском языке. Кроме того, имя шага можно параметризировать – передать в него значения аргументов, передающихся в шаг.
Продемонстрируем на примере
При использовании данного шага в тесте получим отчет:
При выполнении шагов автотеста бывает очень полезно выводить в отчет разного рода информацию. Для этих целей в Allure служат вложения.
• value/name — наименование вложения;
• type — тип информации в соответствии со стандартом MIME;
• content — содержимое вложения;
• fileExtension — опциональное расширение файла вложения, начинающееся с точки.
Вложения к отчету можно прикреплять 2 способами: с помощью аннотации @Attachment и с помощью статического метода addAttachment класса Allure.
В данном способе создается метод, возвращающий массив байтов, над ним размещается аннотация @Attachment. При использовании данного метода считанная информация будет добавлена в отчет в виде файла с соответствующим расширением. Наименование вложения будет таким же, как и имя вызываемого метода.
Продемонстрируем на примере
Создадим метод, который будет зачитывать вложение:
Создадим тестовый шаг, который будет использовать данный метод:
Ну и наконец напишем тест, в котором будет использоваться наш шаг:
В результате прогона данного теста получим отчет:
В аннотации @Attachment можно задавать дополнительные уточняющие параметры:
При использовании данного метода в своих шагах attachment получит наименование «Вложение», содержимое вложения подсветится в соответствии с шаблоном «json», а само вложение будет сохранено в формате ".txt":
Если поменять тип на «plain/text», то никакой характерной для json-style подсветки ключей-значений уже не будет:
В данном способе можно прикрепить вложение к шагу теста/тесту, используя перегруженный статический метод addAttachment из класса Allure. В этот метод можно передавать до 4 аргументов — 2 из них обязательны (имя вложения и сам прикладываемый контент), 2 опциональны (расширение файла и MIME-тип).
Кроме наиболее известных аннотаций @Step и @Attachment, Allure в своем составе имеет целый ряд других аннотаций:
@Description — аннотация, размещаемая над тестом или шагом. Позволяет прикрепить описание к тесту или шагу теста. Данная аннотация может принимать параметры «value» — текст описания и «useJavaDoc». При установке значения «true» последнему параметру, в качестве описания будет браться джавадок, размещенный над методом.
Приведем пример использования данной аннотации
@Epic — аннотация, размещаемая над тестом. Позволяет группировать тесты по эпикам. Данная аннотация принимает параметр «value» — наименование эпика.
@Epics — тоже самое, что и @Epic, но в качестве параметра «value» принимает массив Epic'ов.
@Feature — аннотация, размещаемая над тестом. Позволяет группировать тесты по проверяемому функционалу. Данная аннотация принимает параметр «value» — наименование функционала.
@Features — тоже самое, что и @Feature, но в качестве параметра «value» принимает массив Feature'ей.
@Story — аннотация, размещаемая над тестом. Позволяет группировать тесты по User story. Данная аннотация принимает параметр «value» — наименование User story.
@Stories — тоже самое, что и @Story, но в качестве параметра «value» принимает массив Story'й.
Приведем пример использования данных аннотаций
При выполнении тестов и последующем формировании отчета, в разделе Behaviors мы увидим, что тесты сгруппированы в многоуровневый список (@Epic → @Feature → @Story):
@Flaky — аннотация, размещаемая над тестом. Позволяет пометить автотест как нестабильный. Если автотест падает хотя бы в одном перезапуске (например, папка «target» между прогонами одного и того же теста не очищается) — в отчете на данном тесте вы увидите знак бомбы. Кроме того, данной аннотацией можно помечать классы с нестабильными тестами.
Приведем пример использования данной аннотации
Обратите внимание, что ветвления в тестах делать не стоит: в данном случае блок if — else используется лишь для того, чтобы сделать тест нестабильным!
При нескольких прогонах теста в режиме перезапуска отчет примет следующий вид:
@Issue — аннотация, размещаемая над тестом. Позволяет линковать автотесты с заведенными Issue. Данная аннотация принимает параметр «value», в котором указывается ID дефекта в баг-треккинговой системе.
@Issues — тоже самое, что и @Issue, но в качестве параметра «value» принимает массив Issue.
@TmsLink — аннотация, размещаемая над тестом. Позволяет линковать автотесты с тестовыми кейсами, шаги которых описаны в системах управления тестированием. Данная аннотация принимает параметр «value», в котором указывается ID теста в системе управления тестированием.
@TmsLinks — тоже самое, что и @TmsLink, но в качестве параметра «value» принимает массив TmsLink'ов.
При генерации отчета Allure подставит вместо символов {} значения, которые были указаны в параметре value Вашей аннотации, и вы получите полноценные ссылки.
Приведем пример использования данных аннотаций
@Link — аннотация, размещаемая над тестом. Позволяет приложить к автотесту ссылки на какие-то внешние ресурсы. Данная аннотация может принимать параметры «name» — наименование ссылки (по умолчанию, url), «value» — синоним «name», «url» — адрес, по которому нужно выполнить переход и «type» — параметр, применяемый для создания иконки для ссылки.
@Links — тоже самое, что и @Link, но в качестве параметра «value» принимает массив Link'ов.
Приведем пример использования данных аннотаций
@Owner — аннотация, размещаемая над тестом. Позволяет указать ответственное лицо за тест. Данная аннотация принимает параметр «value», в котором указывается информация об авторе автотеста.
Приведем пример использования данной аннотации
@Severity — аннотация, размещаемая над тестом. Позволяет указать уровень критичности функционала, проверяемого автотестом. Данная аннотация принимает параметр «value», который может быть одним из элементов enum SeverityLevel: BLOCKER, CRITICAL, NORMAL, MINOR или TRIVIAL.
Приведем пример использования данной аннотации
Allure умеет работать с параметризованными автотестами. Рассмотрим на примере JUnit 4.12.
Для начала создадим тестовый класс с параметризованными тестами следующего вида:
Теперь прогоним наш тест и соберем отчет:
Allure представляет наш параметризованный тест как набор тестов, если провалиться в какой-либо тест, то мы получим детальную информацию о прогоне именно этого кейса.
По умолчанию на вкладке «Categories» Allure-отчета все прогнанные тестовые методы делятся на 2 категории: дефекты продукта (failed tests) и дефекты теста (broken tests). Для того, чтобы сделать кастомную классификацию, необходимо подложить файл categories.json в директорию «target/allure-results».
Описание атрибутов:
• name — наименование категории. Оно будет отображаться на вкладке «Categories» на самом верхнем уровне классификации. Обязательный атрибут.
• matchedStatuses — список статусов, с одним из которых должен завершиться тест, чтобы попасть в данную категорию. Из коробки доступны статусы «failed», «broken», «passed», «skipped» и «unknown». Необязательный атрибут.
• messageRegex — регулярное выражение, которому должно соответствовать Exception-сообщение, чтобы попасть в данную категорию. Необязательный атрибут.
• traceRegex — регулярное выражение, которому должно соответствовать Exception-StackTrace, чтобы попасть в данную категорию. Необязательный атрибут.
Теперь прогоним тесты, обнаруживающие такие дефекты, и посмотрим, как будет выглядеть отчет на вкладке «Categories»:
Allure-отчет позволяет выводить на своей главной странице в специальном блоке информацию о тестовом окружении, на котором были прогнаны тесты. Выглядит это так:
Информация, которая отображается в данном блоке, попадает туда из специального файла environment.properties.
Приведем пример данного файла:
Данный файл необходимо подложить в директорию «target/allure-results» до сборки html-отчета. Сделать это можно вручную, а можно использовать maven-resources-plugin.
Приведем пример его использования в данной ситуации, при условии размещения environment.properties в поддиректории resources директории test. Для этого модифицируем pom.xml:
Теперь при сборке проекта environment.properties будет попадать в «target/allure-results» и участвовать в построении html-отчета.
Во второй части лонгрида мы постарались подробно рассказать об аннотациях в Allure, привели примеры их использования. Затронули категории дефектов, тестовое окружение и способы вывода информации в отчет. Приглашаем к обсуждению в комментариях.
Подписывайтесь на блог ЕФС, следите за новыми публикациями. Скоро мы снова расскажем что-то новое и полезное про Allure.
Шаг теста. Определение и аннотация @Step
Для визуализации процессов, протекающих в ваших тестах, необходимо использовать шаги. Шаг должен представлять какое-то атомарное действие или проверку. Собственно последовательность шагов и представляет ваш тест. Для наглядности в шаге должны быть описаны входные параметры, а также ожидаемый и фактический результат, если шаг представляет собой проверку.
В Allure для обозначения тестового шага над методом необходимо проставить аннотацию @Step. Затем необходимые шаги-методы включаются в тело тестового метода: тесты с аннотацией @Test.
Рассмотрим пример
Создадим метод с аннотацией @Step, который проверяет соответствие суммы двух слагаемых ожидаемому результату:
@Step
public static void checkSumStep(int num1, int num2, int expectedSum) {
Assert.assertTrue("Сумма слагаемых не соответствует ожидаемому значению", num1 + num2 == expectedSum);
}Теперь создадим тестовый метод, использующий данный шаг:
@Test
public void simpleTest2() {
checkSumStep(3, 2, 5);
checkSumStep(5, 4, 9);
}При прогоне данного автотеста мы получим следующий отчет:
Аннотация @Step умеет принимать параметр «value», который позволяет указывать имя шага на русском языке. Кроме того, имя шага можно параметризировать – передать в него значения аргументов, передающихся в шаг.
Продемонстрируем на примере
@Step("Проверка разности числа {num1} и числа {num2}")
public static void checkSubtractionStep(int num1, int num2, int expectedResult) {
Assert.assertTrue("Результат вычитания не соответствует ожидаемому значению", num1 - num2 == expectedResult);
}При использовании данного шага в тесте получим отчет:
Стоит отметить, что в случае использования объекта в качестве аргумента метода, есть возможность вывести в названии шага значение одного из полей этого объекта. Для этого необходимо в value указать имя поля в виде {object.fieldName}
Вывод информации в отчет при выполнении шагов теста. Вложения
При выполнении шагов автотеста бывает очень полезно выводить в отчет разного рода информацию. Для этих целей в Allure служат вложения.
Вложение — это информация различного типа в виде файла, который может быть прикреплен к тестовому шагу или тесту.Вложения могут иметь 4 характеристики:
• value/name — наименование вложения;
• type — тип информации в соответствии со стандартом MIME;
• content — содержимое вложения;
• fileExtension — опциональное расширение файла вложения, начинающееся с точки.
Вложения к отчету можно прикреплять 2 способами: с помощью аннотации @Attachment и с помощью статического метода addAttachment класса Allure.
Прикрепление вложений с помощью аннотации @Attachment
В данном способе создается метод, возвращающий массив байтов, над ним размещается аннотация @Attachment. При использовании данного метода считанная информация будет добавлена в отчет в виде файла с соответствующим расширением. Наименование вложения будет таким же, как и имя вызываемого метода.
Продемонстрируем на примере
Создадим метод, который будет зачитывать вложение:
@Attachment
public static byte[] getBytes(String resourceName) throws IOException {
return Files.readAllBytes(Paths.get("src/main/resources", resourceName));
}Создадим тестовый шаг, который будет использовать данный метод:
@Step("Проверка эквивалентности строки {str1} строке {str2}")
public static void checkStringEqualsStep(String str1, String str2) throws IOException {
Assert.assertTrue("Строки не эквивалентны", str1.equals(str2));
getBytes("picture.jpg");
getBytes("text.txt");
}Ну и наконец напишем тест, в котором будет использоваться наш шаг:
@Test
public void simpleTest4() throws IOException {
String darkSouls = "Dark souls 3";
checkStringEqualsStep(darkSouls, darkSouls);
}
В результате прогона данного теста получим отчет:
В аннотации @Attachment можно задавать дополнительные уточняющие параметры:
@Attachment(value = "Вложение", type = "application/json", fileExtension = ".txt")
public static byte[] getBytesAnnotationWithArgs(String resourceName) throws IOException {
return Files.readAllBytes(Paths.get("src/main/resources", resourceName));
}При использовании данного метода в своих шагах attachment получит наименование «Вложение», содержимое вложения подсветится в соответствии с шаблоном «json», а само вложение будет сохранено в формате ".txt":
Если поменять тип на «plain/text», то никакой характерной для json-style подсветки ключей-значений уже не будет:
Также можно поэкспериментировать с fileExtension, например, указать ".doc". В этом случае вложение будет сохранено в формате, характерном для MS Word '97.
Прикрепление вложений с помощью статического метода addAttachment класса Allure
В данном способе можно прикрепить вложение к шагу теста/тесту, используя перегруженный статический метод addAttachment из класса Allure. В этот метод можно передавать до 4 аргументов — 2 из них обязательны (имя вложения и сам прикладываемый контент), 2 опциональны (расширение файла и MIME-тип).
@Step("Добавить ссылку на Сбербанк")
public static void addLinkSber() {
String link = "http://sberbank.ru";
Allure.addAttachment("Результат", "text/plain", link);
}Несмотря на то, что MIME-типы необходимо указывать довольно часто, их приходится прописывать «вручную». В поставку Allure не входит класс с константами допустимых типов.
Другие аннотации Allure
Кроме наиболее известных аннотаций @Step и @Attachment, Allure в своем составе имеет целый ряд других аннотаций:
Аннотация @Description
@Description — аннотация, размещаемая над тестом или шагом. Позволяет прикрепить описание к тесту или шагу теста. Данная аннотация может принимать параметры «value» — текст описания и «useJavaDoc». При установке значения «true» последнему параметру, в качестве описания будет браться джавадок, размещенный над методом.
Приведем пример использования данной аннотации
@Test
@Description(value = "Тест проверяет эквивалентность единицы единице")
public void simpleTest7_1() {
Assert.assertTrue(1 == 1);
}
Аннотации функциональности
@Epic — аннотация, размещаемая над тестом. Позволяет группировать тесты по эпикам. Данная аннотация принимает параметр «value» — наименование эпика.
@Epics — тоже самое, что и @Epic, но в качестве параметра «value» принимает массив Epic'ов.
@Feature — аннотация, размещаемая над тестом. Позволяет группировать тесты по проверяемому функционалу. Данная аннотация принимает параметр «value» — наименование функционала.
@Features — тоже самое, что и @Feature, но в качестве параметра «value» принимает массив Feature'ей.
@Story — аннотация, размещаемая над тестом. Позволяет группировать тесты по User story. Данная аннотация принимает параметр «value» — наименование User story.
@Stories — тоже самое, что и @Story, но в качестве параметра «value» принимает массив Story'й.
Аннотации @Epic/Epics, @Feature/Features, @Story/Stories можно отнести к аннотациям функциональности. Данные аннотации группируют тесты по функциональности в разделе Behaviors(Функциональность) Allure-отчета.
Приведем пример использования данных аннотаций
@Epic(value = "Математика")
@Feature(value = "Простые математические операции")
@Story(value = "Сложение")
@Test
public void sumTest() {
Steps.checkSummationStep(5, 4, 9);
}
@Epic(value = "Математика")
@Feature(value = "Простые математические операции")
@Story(value = "Вычитание")
@Test
public void subTest() {
checkSubtractionStep(8, 2, 6);
}
@Epics(value = {@Epic(value = "Математика"), @Epic(value = "Геометрия")})
@Features(value = {@Feature(value = "Тригонометрия"), @Feature(value = "Простые математические операции")})
@Stories(value = {@Story(value = "Синус"), @Story(value = "Синусоида")})
@Test
public void checkSinTest() {
checkSinStep(0, 0);
}
При выполнении тестов и последующем формировании отчета, в разделе Behaviors мы увидим, что тесты сгруппированы в многоуровневый список (@Epic → @Feature → @Story):
Аннотация @Flaky
@Flaky — аннотация, размещаемая над тестом. Позволяет пометить автотест как нестабильный. Если автотест падает хотя бы в одном перезапуске (например, папка «target» между прогонами одного и того же теста не очищается) — в отчете на данном тесте вы увидите знак бомбы. Кроме того, данной аннотацией можно помечать классы с нестабильными тестами.
Приведем пример использования данной аннотации
Обратите внимание, что ветвления в тестах делать не стоит: в данном случае блок if — else используется лишь для того, чтобы сделать тест нестабильным!
@Test
@Flaky
public void testDemoFlaky() {
int randomNum = ThreadLocalRandom.current().nextInt(0, 2);
if (randomNum == 0) {
Assert.assertTrue(true);
} else {
Assert.assertTrue(false);
}
}
При нескольких прогонах теста в режиме перезапуска отчет примет следующий вид:
Аннотации ссылок на тест-кейсы и дефекты
@Issue — аннотация, размещаемая над тестом. Позволяет линковать автотесты с заведенными Issue. Данная аннотация принимает параметр «value», в котором указывается ID дефекта в баг-треккинговой системе.
@Issues — тоже самое, что и @Issue, но в качестве параметра «value» принимает массив Issue.
@TmsLink — аннотация, размещаемая над тестом. Позволяет линковать автотесты с тестовыми кейсами, шаги которых описаны в системах управления тестированием. Данная аннотация принимает параметр «value», в котором указывается ID теста в системе управления тестированием.
@TmsLinks — тоже самое, что и @TmsLink, но в качестве параметра «value» принимает массив TmsLink'ов.
Аннотации данной группы добавляют ссылки на дефект/тест-кейс в Allure-отчет.Чтобы из ID дефекта/тест-кейса, указанного в параметре «value», получить полноценную ссылку, необходимо в allure.properties (который должен быть размещен в classpath, например, в src/test/resources) описать шаблон ссылки до соответствующего дефекта/тест-кейса.
allure.link.issue.pattern=https://example.org/issue/{}
allure.link.tms.pattern=https://example.org/tms/{}
При генерации отчета Allure подставит вместо символов {} значения, которые были указаны в параметре value Вашей аннотации, и вы получите полноценные ссылки.
Приведем пример использования данных аннотаций
@Test
@Issue(value = "FGY-4627")
@TmsLinks({@TmsLink(value = "TL-135"), @TmsLink(value = "TL-158")})
public void simpleTest15() {
Assert.assertTrue(1 == 1);
}
@Test
@TmsLink(value = "TL-678")
public void simpleTest18() {
Assert.assertTrue(1 == 1);
}
Аннотации прочих ссылок
@Link — аннотация, размещаемая над тестом. Позволяет приложить к автотесту ссылки на какие-то внешние ресурсы. Данная аннотация может принимать параметры «name» — наименование ссылки (по умолчанию, url), «value» — синоним «name», «url» — адрес, по которому нужно выполнить переход и «type» — параметр, применяемый для создания иконки для ссылки.
@Links — тоже самое, что и @Link, но в качестве параметра «value» принимает массив Link'ов.
Приведем пример использования данных аннотаций
@Test
@Link(name = "Ссылка", url = "http://yandex.ru")
public void checkSubtractionWithLinkTest() {
checkSubtractionStep(15, 5, 10);
}
@Test
@Links(value = {@Link(name = "Ссылка1", url = "http://sberbank.ru"),
@Link(name = "Ссылка2", url = "http://yandex.ru")})
public void checkSubtractionWithLinksTest() {
checkSubtractionStep(14, 5, 9);
}
Аннотация @Owner
@Owner — аннотация, размещаемая над тестом. Позволяет указать ответственное лицо за тест. Данная аннотация принимает параметр «value», в котором указывается информация об авторе автотеста.
Приведем пример использования данной аннотации
@Test
@Owner(value = "Пупкин Валерий Иванович")
public void testDemoOwner() {
checkSumStep(1, 2, 3);
}
Аннотация @Severity
@Severity — аннотация, размещаемая над тестом. Позволяет указать уровень критичности функционала, проверяемого автотестом. Данная аннотация принимает параметр «value», который может быть одним из элементов enum SeverityLevel: BLOCKER, CRITICAL, NORMAL, MINOR или TRIVIAL.
Приведем пример использования данной аннотации
@Test
@Severity(value = SeverityLevel.BLOCKER)
public void testDemoSeverity() {
checkSubtractionStep(6, 1, 5);
}
Параметризованные автотесты в Allure
Allure умеет работать с параметризованными автотестами. Рассмотрим на примере JUnit 4.12.
Для начала создадим тестовый класс с параметризованными тестами следующего вида:
@RunWith(Parameterized.class)
public class ParamsTests {
@Parameter
public int operand1;
@Parameter(1)
public int operand2;
@Parameter(2)
public int expectedResult;
@Parameters(name = "operand1 = {0} | operand2 = {1} | expectedResult = {2}")
public static Collection<Integer[]> dataProvider() {
return Arrays.asList(new Integer[][]{
{1, 2, 3},
{2, 4, 6},
{5, 6, 11},
{7, 5, 12},
{2, 4, 5},
{4, 1, 5},
{8, 2, 11}
});
}
@Test
public void checkSum() {
Assert.assertTrue("Сумма слагаемых не соответствует ожидаемому значению", operand1 + operand2 == expectedResult);
}
}
Теперь прогоним наш тест и соберем отчет:
Allure представляет наш параметризованный тест как набор тестов, если провалиться в какой-либо тест, то мы получим детальную информацию о прогоне именно этого кейса.
Категории дефектов. Распределение дефектов по категориям
По умолчанию на вкладке «Categories» Allure-отчета все прогнанные тестовые методы делятся на 2 категории: дефекты продукта (failed tests) и дефекты теста (broken tests). Для того, чтобы сделать кастомную классификацию, необходимо подложить файл categories.json в директорию «target/allure-results».
Если в pom.xml у Вас подключен allure-maven плагин, то categories.json можно разместить в поддиректории resources директории testПриведем пример кастомной классификации дефектов. Создадим файл categories.json:
[
{
"name": "Неизвестная проблема",
"matchedStatuses": ["broken", "failed"],
"messageRegex": ".*что-то пошло не так.*"
},
{
"name": "Нет данных",
"matchedStatuses": ["broken"],
"traceRegex": ".*NullPointerException.*"
},
{
"name": "Product defects",
"matchedStatuses": ["failed"]
},
{
"name": "Test defects",
"matchedStatuses": ["broken"]
}
]
Описание атрибутов:
• name — наименование категории. Оно будет отображаться на вкладке «Categories» на самом верхнем уровне классификации. Обязательный атрибут.
• matchedStatuses — список статусов, с одним из которых должен завершиться тест, чтобы попасть в данную категорию. Из коробки доступны статусы «failed», «broken», «passed», «skipped» и «unknown». Необязательный атрибут.
• messageRegex — регулярное выражение, которому должно соответствовать Exception-сообщение, чтобы попасть в данную категорию. Необязательный атрибут.
• traceRegex — регулярное выражение, которому должно соответствовать Exception-StackTrace, чтобы попасть в данную категорию. Необязательный атрибут.
Теперь прогоним тесты, обнаруживающие такие дефекты, и посмотрим, как будет выглядеть отчет на вкладке «Categories»:
Тестовое окружение. Блок ENVIRONMENT на главной странице отчета
Allure-отчет позволяет выводить на своей главной странице в специальном блоке информацию о тестовом окружении, на котором были прогнаны тесты. Выглядит это так:
Информация, которая отображается в данном блоке, попадает туда из специального файла environment.properties.
Приведем пример данного файла:
OS.version=Windows 10 Pro
JDK.version=jdk1.8.0_162
MAVEN.version=Apache Maven 3.5.2
allure-junit4.version=2.6.0
allure-report.version=2.6.0
Данный файл необходимо подложить в директорию «target/allure-results» до сборки html-отчета. Сделать это можно вручную, а можно использовать maven-resources-plugin.
Приведем пример его использования в данной ситуации, при условии размещения environment.properties в поддиректории resources директории test. Для этого модифицируем pom.xml:
<build>
<plugins>
...
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${allure.results.directory}</outputDirectory>
<resources>
<resource>
<directory>src/test/resources</directory>
<includes>
<include>environment.properties</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
Теперь при сборке проекта environment.properties будет попадать в «target/allure-results» и участвовать в построении html-отчета.
При запуске тестов на Jenkins, categories.json не будет самостоятельно копироваться в «target/allure-results». Его также очень удобно добавить в секцию includes maven-resources-plugin'а.
Заключение
Во второй части лонгрида мы постарались подробно рассказать об аннотациях в Allure, привели примеры их использования. Затронули категории дефектов, тестовое окружение и способы вывода информации в отчет. Приглашаем к обсуждению в комментариях.
Подписывайтесь на блог ЕФС, следите за новыми публикациями. Скоро мы снова расскажем что-то новое и полезное про Allure.
