Привет, Хабр. Сегодня поговорим о новой версии Allure Report — Allure 3, а именно о её модульной архитектуре. В ней можно настроить сколько угодно отображений тестовой иерархии в разных форматах; я покажу это на простом примере. В какой ситуации может это быть полезно?
Когда с тестами работает несколько команд, обычно удобно, чтобы у каждой был своя классификация тестов. Кто-то хочет, чтобы тесты были организованы по фичам, т.е. близко к требованиям. Кто-то предпочитает видеть организацию по сюитам - ближе к коду проверяемого приложения.
Мы сделаем так, чтобы при каждом запуске тестов Allure генерировал два отчёта, каждый со своим отображением тестов. Тренироваться будем на PyTest; все принципы можно применять к коду, на котором рабоотал Allure 2 — менять в старых тестах ничего не нужно.
1. Подготовка
Код демонстрации
https://github.com/rattus-aristarchus/allure-3-plugins-demo
Список зависимостей
Установка
Перед началом работы нужно установить:
Затем нам понадобится проект Python. Если его нужно создать с нуля, проще всего скачать проект-«болванку» с Allure Start — этот инструмент работает с Allure 3 так же, как с прошлыми версиями. Правда, нам понадобится добавить к скачанному проекту файл настроек allurerc.js - об этом ниже.
В скачанном проекте установим зависимости:
pip install -r requirements.txt
2. Пробные тесты
Напишем несколько тестов. Их содержание нам безразлично, зато нас будет интересовать организация их в разные иерархии - это мы реализуем через декораторы:
import allure # Сортировка по фичам: @allure.feature("Feature 1") # Сортировка по сюитам: @allure.suite("Suite 1") @allure.title("Первый тест") def test_allure_3_first(): pass @allure.feature("Feature 2") @allure.suite("Suite 2") @allure.title("Второй тест") def test_allure_3_second(): pass @allure.feature("Feature 1") @allure.suite("Suite 2") @allure.title("Третий тест") def test_allure_3_third(): pass
Третий тест у нас попадёт в разные категории в зависимости от того, организуем мы тесты по фичам или по сюитам.
3. Настройка отчётов
Теперь настроим отчёты, которые обеспечат нам несколько отображений иерархии тестов.
Для этого нужно создать файл настроек allurerc.js в корне проекта:
export default { // Общий заголовок name: "Демонстрация деревьев в Allure 3", // Путь к папке с отчётом output: "./allure-report", // Путь к файлу с историей historyPath: "./test-history/history.jsonl", // Отчёты plugins: { // Отчёт с группировкой по фичам "awesome-by-feature": { import: "@allurereport/plugin-awesome", options: { // Имя отчёта reportName: "Группируем по фичам", // Язык отчёта reportLanguage: "ru", // Поля, по которым группируются тесты в отчёте groupBy: ["feature"], }, }, // Отчёт с группировкой по сюитам "awesome-by-suite": { import: "@allurereport/plugin-awesome", options: { reportName: "Группируем по сюитам", reportLanguage: "ru", groupBy: ["suite"], }, }, }, };
Сейчас нас интересует поле plugins. В нём можно импортировать несколько плагинов или один плагин несколько раз; каждый раз будет создан отдельный отчёт.
Формат отчёта определяется полем import; здесь мы будем использовать базовый для Allure 3 - awesome.
В options мы прописываем имя отчёта, язык, и, главное, поля, по которым будут группироваться тесты. Здесь можно прописать несколько полей, и они будут выстроены в иерархию (первое поле - первый уровень иерархии). У нас сейчас прописан только один уровень, но можно было бы написать:
groupBy: ["epic", "feature", "story"],
Тогда мы бы получили трёхуровневую иерархию.
4. Результат
Теперь сгенерируем отчёты.
Тесты и генерация отчёта (а также создание файла истории) в Allure 3 выполняются одной командой такого формата: npx allure run -- <команда_запуска_тестов>.
В нашем случае команда выглядит так:
npx allure run --config=./allurerc.js -- "pytest --alluredir allure-results"
В флаге --config для allure run здесь указан путь к файлу конфигурации.
После того, как тесты выполнены, отчёт можно открыть командой allure open <местоположение_отчёта> (у нас местоположение по умолчанию, ./allure-report, поэтому можно просто allure open).
И вот перед нами два плагина:

В одном отображении третий тест находится в первой фиче:

В другом - во второй сюите:

5. Allure 2 в Allure 3
Строго говоря, это поведение можно было реализовать и в старом Аллюре. Чтобы разобраться, что тут изменилось, запустим старый Аллю�� отдельным отчётом в новом Аллюре.
Для этого добавим несколько строк в allurerc.js, чтобы поле plugins выглядело так:
plugins: { // Отчёт с группировкой по фичам "awesome-by-feature": { import: "@allurereport/plugin-awesome", options: { reportName: "Группируем по фичам", reportLanguage: "ru", groupBy: ["feature"], }, }, // Отчёт с группировкой по сюитам "awesome-by-suite": { import: "@allurereport/plugin-awesome", options: { reportName: "Группируем по сюитам", reportLanguage: "ru", groupBy: ["suite"], }, }, // Классический отчёт "classic view": { // Импорт пакета классического отчёта import: "@allurereport/plugin-classic", options: { reportName: "Классическое отображение", reportLanguage: "ru", }, }, },
Обратите внимание, что в последнем отчёте мы использовали другой плагин, чем раньше: "@allurereport/plugin-classic"; ровно так указывается формат отчёта. Список доступных плагинов можно посмотреть здесь.
Запустим тесты, откроем Аллюр и увидим, что появился третий отчёт:

В нём - привычный интерфейс Allure 2. Отображение по фичам и сюитам здесь зашито в отдельные вкладки:

Итак, если старое отображение привычнее - оно никуда не делось.
6. Отличие нового подхода
Allure 2 предоставлял ограниченное число жёстко прописанных отображений; сейчас же тесты можно группировать по любому полю (tag, label), и организовывать иерархию этих полей в любом порядке.
Хотим сгруппировать по уровням (API, UI)? Добавляем к тесту метку (т.е. label), определяющую его уровень:
@allure.label("level", "UI") def test_ui(): pass @allure.label("level", "API") def test_api(): pass
И добавляем в allurerc.js новый плагин, использующий имя нашей метки в groupBy:
"layer view": { import: "@allurereport/plugin-awesome", options: { reportName: "Группируем по уровням", reportLanguage: "ru", groupBy: ["level"], }, },
Или вот другой возможный кейс использования модульных отчётов. Предположим, мы начинаем новый проект, который в будущем может вольётся в старый, а может и нет. Заранее может быть неизвестно, какая структура отображения будет наиболее удобной; это не беда - можно просто создать новый отчёт, а дальше при необходимости менять в нём поля.
Выводы
Модульная архитектура позволяет приспособить инструмент к рабочему процессу, а не наоборот. И ещё - с ней всегда интересно экспериментировать. Весь код Аллюра открытый, все возможности можно подробно изучить на GitHub.
