Почему в allure отчете отсутствует тело теста
Мне понравился механизм аспектно-ориентированного программирования (АОП), который используется в Allure Framework для перехвата выполнения тестовых шагов, отмеченных аннотацией @Step. И я попробовал применить его в автотестировании, не подключая к тестам таких монстров, как Spring или Guice.
В этой статье вы найдете несколько полезных примеров использования аспектов.
В двух словах аспектно-ориентированное программирование — это концепция, разделения функциональности программы для упрощения ее разложения на модули. Здесь я не буду останавливаться на теории, чтобы быстрее перейти к практическим примерам. Неплохая статья для знакомства с подходом есть на Хабре. А в Википедии есть словарь основных терминов АОП.
С точки зрения автотестирования это механизм, который позволяет в существующий большой проект дописать файлик Aspect с так называемыми Advice, которые будут выполняться в нужных местах и добавлять некоторые полезные инструменты в весь проект.
В общем случае выглядит это так
Все тестовые шаги мы помечаем аннотацией @Step — это способ отделить их от остальных методов. Если в ходе работы приложения выполняется метод, который соответствует какому-либо указателю @Pointcut из наших аспектов, то в зависимости от вида Advice-а будет:
- выполнен код Advice, а затем уже метод (@Before);
- выполнен метод, а затем уже Advice (@After, @AfterReturning);
- выполнен код Advice, внутри которого можно запустить исходный метод (один или несколько раз) или же не делать ничего (@Around).
Например, если при выполнении метода вываливается исключение, его можно перехватить и “проглотить” с помощью аспекта, записав при этом в лог. Со стороны же выполнение будет выглядеть так, будто программа выполнилась без ошибок.
Advice имеет доступ к телу метода — мы можем получить параметры, с которыми его вызывают и использовать эти данные для выполнения каких-то своих действий — той же записи в log.
Allure Framework, который мы (и многие другие) используем для формирования отчетов автотестов, построен как раз на механизмах AOP. Allure-адаптер делает ровно то же самое — отлавливает аннотации @Step в последовательности выполняющихся методов. А описание того, что необходимо сделать при обнаружении аннотации, хранится в аспекте. Среди прочего там есть добавление информации о шаге в отчет. Если шаг выполняется успешно, он помечается в отчете зеленым, если нет — красным.
Честно говоря, я и набрел на аспектно-ориентированное программирование, пока ковырялся в Allure, пытаясь реализовать там необходимое мне поведение. Наверное, для моих целей можно было бы использовать тот же Lombok, но библиотека AspectJ уже есть в комплекте с Allure и легко внедряется в наши проекты. Плюс на примере Allure было отлично видно, как с ее помощью получить то, что мне нужно. А усложнение и увеличение числа используемых инструментов не входило в планы.
Полезные примеры применения аспектов в автотестах
Для сборки я использую Gradle, в Maven все будет немного иначе.
Прежде чем переходить к конкретным шагам, необходимо подключить AspectJ с помощью зависимостей:
compile 'org.aspectj:aspectjrt:1.9.2' compile ‘org.aspectj:aspectjweaver:1.9.2’Я использую плагин io.qameta.allure:allure-gradle:2.8.1, в котором уже есть библиотека “aspectjweaver”, т.е. для Allure достаточно указать версию:
allure
Исходники примеров, изложенных ниже, вы можете найти в моем GitHub.
Сквозное логирование
Аспекты позволяют добавить сквозное логирование ко всему проекту. Для этого достаточно создать всего лишь один класс, который будет записывать в log-файл данные о выполнении метода, обернутого в аспект.
Предположим, у нас есть простейший тест, который открывает главную страницу Google, выполняет поиск по какому-то запросу и сравнивает результаты с ожидаемыми (берет один из веб-элементов на странице — в нашем случае строку с количеством результатов — и проверяет совпадение с заданным текстом).
@Test public void allureLogTest ()
В этом примере я специально задал кривой текст для сравнения, чтобы тест упал.
Если мы не используем другие инструменты (например, встроенный механизм Selenide, который позволяет добавлять своих слушателей на разные события), то тест будет работать молча, не сообщая о текущих выполняемых шагах в консоль.
Под капотом у нас есть аннотации @Step, которые мы используем для шагов, попадающих в отчет Allure. Но по умолчанию эти шаги в консоль не выводятся.
public class GoogleSteps < @Step("Получаем сводку по результатам поиска") @Attachment public static String getResultStats() < return Selenide.$("#result-stats").text(); >@Step("Выполняем поиск по запросу: ") public static void searchFor(String request) < Selenide.$("[name='q']").setValue(request); Selenide.$("[name='btnK']").click(); >@Step("Открываем страницу поиска") public static void openSearchPage() < Selenide.open("https://www.google.ru/"); >> Вывести их в консоль с минимальными вмешательствами можно с помощью аспектов. Достаточно создать аспект — фактически, обычный класс java со специальной аннотацией — который будет выделять название шагов @Step.
@Aspect public class AllureLogAspect
Внутри мы должны указать pointcut, где будет срабатывать аспект. Допустим, нам нужно, чтобы он срабатывал перед запуском любого метода, в котором проставлена аннотация io.qameta.allure.Step:
@Before("@annotation(io.qameta.allure.Step) && execution(* *(..))") public void beforeStep(JoinPoint joinPoint)
@Before означает, что аспект должен сработать перед запуском метода. В этот метод передается точка присоединения (JoinPoint), содержащая указатель на запускаемый метод. Здесь же мы можем получить параметры запуска:
private String getStepName(JoinPoint joinPoint) < MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature(); MapparametersMap = getParametersMap(joinPoint); Method method = methodSignature.getMethod(); Step step = method.getAnnotation(Step.class); String stepName = step.value(); return Optional.of(stepName) .filter(StringUtils::isNoneEmpty) .map(it -> processNameTemplate(it, parametersMap)) .orElse(methodSignature.getName()); >
Отмечу, что вместо
return Optional.of(stepName) .filter(StringUtils::isNoneEmpty) .map(it -> processNameTemplate(it, parametersMap)) .orElse(methodSignature.getName());
можно было написать просто
return stepName; Но в этом случае мы получили бы просто исходный текст аннотации и не имели бы возможности заменить подстановочные символы. Чуть более сложная запись позволяет при открывании страницы увидеть в консоли ее адрес, переданный в метод.
Что мы получаем в результате?
При запуске теста еще до открытия страницы выполняется метод beforeStep, из него мы выделяем адрес страницы и пишем в лог. Дальше управление возвращается исходному методу.
Чтобы лог был полным после его выполнения мы подставим еще один аспект с @AfterReturning:
@AfterReturning( pointcut = "@annotation(io.qameta.allure.Step) && execution(* *(..))", returning = "result" ) public void afterStep(JoinPoint joinPoint, Object result) < String stepName = getStepName(joinPoint); log.info("END: " + stepName); if(result != null) < log.info("RESULT: " + result); >>
Здесь помимо аналогичной записи в лог мы также проверяем, есть ли какой-то результат вызова метода. Если результат не пустой, он также выводится в консоль.
С описанием аспекта мы закончили. Осталось создать в папке /resources/META-INF мета-файл aop-ajc.xml, в котором следует указать пульт до нового класса:
Теперь когда мы запускаем тест, в консоль выводятся все шаги, которые попадают в отчет Allure. Параллельно мы получаем сводку по результатам.
У меня на проектах задача логирования в консоль решается через встроенный механизм Selenide, который позволяет добавлять listener-ы на различные события. А аспекты используются для других задач. Например, для логирования HTTP-запросов из созданных через OpenAPI-генератор Swagger-клиентов. Также с помощью AOP я добавляю текущее время и дату к названиям тестовых шагов в отчетах Allure. Так удобнее утром разбирать ночные прогоны. Еще один вариант использования — логирование SQL-запросов в БД.
Механизм повторов
Аспекты позволяют реализовать необходимое количество повторов тестовых шагов.
Предположим, некий тестовый шаг со специальной аннотацией не всегда проходит с первого раза. Мы хотели бы, чтобы при неудаче у нас было еще 2-3 попытки. И если хотя бы одна из них выполнилась корректно, шаг считался бы зеленым.
В качестве примера я сделал шаг checkRandom(), где мы генерируем случайное число от 0 до 9 и проверяем, что оно равно desiredValue:
public class CommonSteps < @Step("Проверяем, что случайное число = ") @WithRetries(20) public static void checkRandom(int desiredValue) < Random random = new Random(); int i = random.nextInt(10); MatcherAssert.assertThat( "Неправильный результат", i, Matchers.equalTo(desiredValue) ); >>Без аспекта тест ожидаемо падает (с соответствующей вероятностью).
Чтобы обеспечить повторы, я создал новую аннотацию @WithRetries. По умолчанию методы, отмеченные этой аннотацией, повторяются 3 раза:
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface WithRetries
Также я создал класс:
@Aspect public class WithRetriesAspect < private static final ThreadLocalprocessingWrapper = ThreadLocal.withInitial(() -> false); private static final Logger log = LoggerFactory.getLogger(WithRetriesAspect.class); public static Boolean isProcessing() < return processingWrapper.get(); >. > В отличие от предыдущего примера, здесь я использую pointcut @Around. Это позволяет полностью контролировать выполнение методов, отмеченных аннотацией @WithRetries.
@Around("@annotation(org.example.aop.annotations.WithRetries) && execution(* *(..))") public Object handleRetries(final ProceedingJoinPoint joinPoint) throws Throwable < processingWrapper.set(true); MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature(); Method method = methodSignature.getMethod(); WithRetries annotation = method.getAnnotation(WithRetries.class); int retryCount = annotation.value(); Throwable storedException = null; Object result = null; boolean processed = false; int i = 0; while (!processed && i < retryCount) < try < result = joinPoint.proceed(); processed = true; >catch(Throwable throwable) < log.warn("Попытка №" +i+":\r\n"+throwable.toString()); storedException = throwable; >i++; >
Разберем, что здесь происходит.
Внутри Advice я получаю из аннотации количество попыток выполнения и пытаюсь исполнить метод. Если возникает исключение, я его перехватываю здесь же и сохраняю в переменную storedException. В конце я проверяю, по какой причине мы вышли из цикла — получили результат или переполнился счетчик попыток. Если какой-то результат есть, я возвращаю его, а в ином случае выкидываю исключение.
processingWrapper.set(false); if(!processed) < assert storedException != null; throw storedException; >return result;
Подключается аспект точно также в файле /resources/META-INF/aop-ajc.xml
Поглощение исключений
Еще один интересный пример возможностей АОП — это обработка исключений таким образом, чтобы при их появлении появлялось предупреждение, но тест не останавливался.
Подход аналогичный предыдущим двум примерам. Я создаю аспект:
@Aspect public class MatcherAssertAspect
Но pointcut здесь немного сложнее.
Такой pointcut сработает на все методы, которые называются assertThat:
@Pointcut("execution(* assertThat(..))") void inMethods()
Следующий pointcut — на все методы, которые расположены в классе org.hamcrest.MatcherAssert:
@Pointcut("execution(* org.hamcrest.MatcherAssert.*(..))") void inMatcherAssert()
А этот pointcut сработает на все публичные методы:
@Pointcut("execution(public * *(..))") void anyPublic()
После объединения всех pointcut-ов у нас остаются все публичные методы с названием assertThat внутри класса org.hamcrest.MatcherAssert.
Внутри аспекта используем тот же Advice @Arround:
@Around("anyPublic() && inMatcherAssert() && inMethods()") public Object handleAssert(final ProceedingJoinPoint joinPoint) throws Throwable < Object result = null; try < result = joinPoint.proceed(); >catch (Throwable throwable) < if (WithRetriesAspect.isProcessing()) < throw throwable; >else < log.warn(throwable.toString()); >> return result; >
Здесь у меня добавлена синхронизация с описанным выше аспектом, обрабатывающим повторы.
Простейший тест для проверки выглядит следующим образом:
@Test void errorsSkippingTest()
Перед запуском также подключаем класс в файле /resources/META-INF/aop-ajc.xml
Используя повторы и поглощение исключений можно обрабатывать самые неприятные тесты — Flaky-тесты. Ты запускаешь их несколько раз подряд с одними и теми же тестовыми данными в одном и том же окружении, а результат оказывается случайным (то зеленые, то красные). Они не несут в себе совершенно никакой полезной информационной нагрузки, но мешают получению данных о работоспособности тестируемого продукта.
Allure-Framework. Работа с кодом
Продолжая серию публикаций о возможностях Allure-framework, сегодня мы поговорим о работе с кодом. Под катом разбираем, что такое шаг теста, как выводить информацию в отчет при выполнении шагов и какие бывают категории дефектов. Кроме того, расскажем об аннотациях Allure. Дальше еще интереснее!
Шаг теста. Определение и аннотация @Step
Для визуализации процессов, протекающих в ваших тестах, необходимо использовать шаги. Шаг должен представлять какое-то атомарное действие или проверку. Собственно последовательность шагов и представляет ваш тест. Для наглядности в шаге должны быть описаны входные параметры, а также ожидаемый и фактический результат, если шаг представляет собой проверку.
В Allure для обозначения тестового шага над методом необходимо проставить аннотацию @Step. Затем необходимые шаги-методы включаются в тело тестового метода: тесты с аннотацией @Test.
Рассмотрим пример
Создадим метод с аннотацией @Step, который проверяет соответствие суммы двух слагаемых ожидаемому результату:
@Step public static void checkSumStep(int num1, int num2, int expectedSum)
Теперь создадим тестовый метод, использующий данный шаг:
@Test public void simpleTest2()
При прогоне данного автотеста мы получим следующий отчет:
Аннотация @Step умеет принимать параметр «value», который позволяет указывать имя шага на русском языке. Кроме того, имя шага можно параметризировать – передать в него значения аргументов, передающихся в шаг.
Продемонстрируем на примере
@Step("Проверка разности числа и числа ") public static void checkSubtractionStep(int num1, int num2, int expectedResult)
При использовании данного шага в тесте получим отчет:
Стоит отметить, что в случае использования объекта в качестве аргумента метода, есть возможность вывести в названии шага значение одного из полей этого объекта. Для этого необходимо в value указать имя поля в виде
Вывод информации в отчет при выполнении шагов теста. Вложения
При выполнении шагов автотеста бывает очень полезно выводить в отчет разного рода информацию. Для этих целей в 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("Проверка эквивалентности строки строке ") public static void checkStringEqualsStep(String str1, String str2) throws IOException
Ну и наконец напишем тест, в котором будет использоваться наш шаг:
@Test public void simpleTest4() throws IOException
В результате прогона данного теста получим отчет:
В аннотации @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()
Аннотации функциональности
@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()
При выполнении тестов и последующем формировании отчета, в разделе 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()
Аннотации прочих ссылок
@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()
Аннотация @Owner
@Owner — аннотация, размещаемая над тестом. Позволяет указать ответственное лицо за тест. Данная аннотация принимает параметр «value», в котором указывается информация об авторе автотеста.
Приведем пример использования данной аннотации
@Test @Owner(value = "Пупкин Валерий Иванович") public void testDemoOwner()
Аннотация @Severity
@Severity — аннотация, размещаемая над тестом. Позволяет указать уровень критичности функционала, проверяемого автотестом. Данная аннотация принимает параметр «value», который может быть одним из элементов enum SeverityLevel: BLOCKER, CRITICAL, NORMAL, MINOR или TRIVIAL.
Приведем пример использования данной аннотации
@Test @Severity(value = SeverityLevel.BLOCKER) public void testDemoSeverity()
Параметризованные автотесты в 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 = | operand2 = | expectedResult = ") public static Collection dataProvider() < return Arrays.asList(new Integer[][]< , , , , , , >); > @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 — наименование категории. Оно будет отображаться на вкладке «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:
. maven-resources-plugin 3.0.2 copy-resources validate copy-resources $ src/test/resources environment.properties Теперь при сборке проекта environment.properties будет попадать в «target/allure-results» и участвовать в построении html-отчета.
При запуске тестов на Jenkins, categories.json не будет самостоятельно копироваться в «target/allure-results». Его также очень удобно добавить в секцию includes maven-resources-plugin’а.
Заключение
Во второй части лонгрида мы постарались подробно рассказать об аннотациях в Allure, привели примеры их использования. Затронули категории дефектов, тестовое окружение и способы вывода информации в отчет. Приглашаем к обсуждению в комментариях.
Подписывайтесь на блог ЕФС, следите за новыми публикациями. Скоро мы снова расскажем что-то новое и полезное про Allure.
- allure
- allure first steps
- allure framework
- allure 2.0
- allure 2
- Блог компании Сбер
- Тестирование IT-систем
- Программирование
- Тестирование веб-сервисов
- Учебный процесс в IT
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allure: Тело сценария отображается не так, как в VA #1111
DoublesunRUS opened this issue Jan 18, 2021 · 1 comment
Allure: Тело сценария отображается не так, как в VA #1111
DoublesunRUS opened this issue Jan 18, 2021 · 1 comment
Comments
Contributor
DoublesunRUS commented Jan 18, 2021
Функционал: Одинаковое отображение сценария в VA и Allure Как разработчик теста Я хочу чтобы дерево шагов сценария отображалось одинаково в VA и Allure
Есть у меня сценарий из одного шага:
Сценарий: Печать существующего документа "ОтзывСогласияНаОбработкуПерсональныхДанных" Дано Печать существующего документа "ОтзывСогласияНаОбработкуПерсональныхДанных"
Этот шаг это сценарий из другого фича файла:
Дано я закрыл все окна клиентского приложения Если нет права "Просмотр" к объекту "Документ.ОтзывСогласияНаОбработкуПерсональныхДанных" тогда Тогда я останавливаю выполнение сценария Дано я получаю список команд печати для объекта метаданных "Документ.ОтзывСогласияНаОбработкуПерсональныхДанных" в переменную "СписокПечатныхФорм" Если '$СписокПечатныхФорм$.Количество() = 0' Тогда Тогда я вызываю исключение "В конфигурации отсутствуют печатные формы для документа ОтзывСогласияНаОбработкуПерсональныхДанных" И я ищу последние 5 документов 'ОтзывСогласияНаОбработкуПерсональныхДанных' по каждой организации в переменную "СписокДокументов" Если '$СписокДокументов$.Количество() = 0' Тогда Тогда я вызываю исключение "В базе отсутствуют документы ОтзывСогласияНаОбработкуПерсональныхДанных" И для каждого значения "СсылкаДокумента" из массива "$СписокДокументов$" Тогда я запоминаю значение выражения 'ПолучитьНавигационнуюСсылку($СсылкаДокумента$)' в переменную "НавигационнаяСсылкаДокумента" Затем я открываю навигационную ссылку "$НавигационнаяСсылкаДокумента$" Если появилось предупреждение тогда Тогда я вызываю исключение "Не удалось открыть навигационную ссылку $НавигационнаяСсылкаДокумента$" И для каждого значения "ПечатнаяФормаДокумента" из массива "$СписокПечатныхФорм$" Тогда я запоминаю значение выражения '$ПечатнаяФормаДокумента$.Представление' в переменную "НаименованиеПечатнойФормы" Если элемент с заголовком "$НаименованиеПечатнойФормы$" присутствует на форме тогда Тогда я нажимаю на кнопку "$НаименованиеПечатнойФормы$" Если появилось предупреждение тогда Тогда я вызываю исключение "Не удалось напечатать форму $НаименованиеПечатнойФормы$ для документа $НавигационнаяСсылкаДокумента$" И я закрываю текущее окно И я закрыл все окна клиентского приложения
Так вот в отчете Allure он выглядит совсем не так. Там какая-то мешанина шагов без соблюдения иерархии.
The text was updated successfully, but these errors were encountered:
Вопросы с меткой [pytest]
Дано: веб-приложение, которое допускает только одно нахождение на сайте (т.е. при запуске второго браузера и авторизации в нем, первого выкидывает) допустим, 40 автотестов фикстура, в которой .
задан 8 ноя 2023 в 13:23
88 показов
Запуск GUI автотестов в GitLab CI\CD с использованием Docker Selenium PyTest
Доброго времени всем. Может у кого то был опыт по запуску автотестов на PyTest Selenium-standalone и docker в GitLab CI. Заранее оговорюсь, что опыт по части devOps почти нулевой и буду признателен за .
задан 7 ноя 2023 в 13:52
Можно ли в рамках прогона одного теста PyTest получить больше одного сообщения об ошибке?
Хочется понять, может ли PyTest работать а-ля Postman, где мы в одном тесте можем провести сколько угодно проверок, и тест отработает все созданные нами проверки. Хочется чтобы тест упал, но только .
задан 30 окт 2023 в 21:31
как использовать *args и **kwargs в pytest
Функция принимает аргументы *args и departments: tuple = None. Как можно написать на нее тесты используя pytest? test_data = ( ((‘Develop’, [1000, 200, 500]), (‘Marketing’, [400, 600, 300]), .
задан 2 окт 2023 в 17:48
Как при генерации отчета pytest allure (json) добавить свой status?
Мне необходимо получиться статус «unknown» при генерации отчета allure pytest (python). Подскажите пожалуйста, как это можно сделать? requirements.txt pytest==7.3.1 allure-pytest==2.13.2 .
задан 17 сен 2023 в 9:59
39 показов
ERROR collecting test session при запуске тестов из make.file
Проект https://gitlab.com/nanuchi/gitlab-cicd-crash-course. В make.file данного проекта есть задача, при которой возникает ошибка: ERROR collecting test session .
задан 31 авг 2023 в 5:49
Ошибка запуска тестов через make.file make: *** [src/.venv/touchfile] Ошибка 9009
Проект https://gitlab.com/nanuchi/gitlab-cicd-crash-course. В make.file данного проекта есть задача, при которой возникает ошибка make: *** [src/.venv/touchfile] Ошибка 9009 SRC_DIR := src test: .
задан 30 авг 2023 в 12:32
149 показов
ModuleNotFoundError: No module named ‘clients’
Пишу проект на питоне. Разбил проект на папки bot и tests. Если запускаю тесты через пайчарм, то все работает, если запускаю через консоль то выдает ошибку: return _bootstrap._gcd_import(name[level:], .
задан 23 авг 2023 в 16:59
Ошибка при передаче фикстуры в параметр функции
Проблема при передаче в параметре фикстуры в функцию Импорт и фикстура: import pytest import requests from selenium import webdriver from selenium.webdriver.common.by import By @pytest.fixture() def .
задан 14 авг 2023 в 21:50
196 показов
Ошибка SSL: CERTIFICATE_VERIFY_FAILED
При запуске теста в PyTest возникает ошибка: requests.exceptions.SSLError: HTTPSConnectionPool(host=’chromedriver.storage.googleapis.com’, port=443): Max retries exceeded with url: /LATEST_RELEASE_114.
задан 21 июл 2023 в 11:52
pytest не запускается
Начал изучать тестирование в Python, а именно модуль pytest. Установил через pip, но при запуске получил ошибку. Попытка запустить pytest через python -m pytest filename, выдает целый ряд ошибок во .
задан 6 июл 2023 в 19:41
20 показов
Как отдебажить получаемый шаблон в Django
Не понимаю, почему не проходит тест шаблона. Падает ошибка: AssertionError: No templates used to render the response. Содержимое объекта response из которого видно что в нем уже есть шаблон products/.
задан 30 июн 2023 в 18:15
75 показов
Почему неправильно считается покрытие в коде с абстрактным классом / методом
Вот так выглядит код, который я хочу протестировать: class AbstractWrapper(ABC): @abstractmethod def func(self) -> None: raise NotImplementedError # * class Wrapper(.
задан 23 июн 2023 в 5:21
134 показа
настройка PyCharm для запуска pytest не работает
настраиваю чтоб pytest запускался с кнопки в PyCharm появляется ошибка: ImportError: No module named ‘ amazing_hunting’ файл pytest.ini: DJANGO_SETTINGS_MODULE = amazing_hunting.settings папка с .