Почему так сложно сделать отчёт, который будет полезен и разработчику, и аналитику, и менеджеру? Написать красивую HTML-оболочку — дело не такое уж и трудозатратное. 

Но одного этого мало. Чтобы отчёт могли читать люди без навыков тестирования и программирования, он должен уметь скрывать технические подробности тестов; а чтобы им по-прежнему могли пользоваться тестировщики и разработчики, код по-прежнему должен быть под рукой, на расстоянии одного-двух кликов.

Нативные отчёты, используемые фреймворками тестирования, здесь обычно не подходят, или не предоставляют нужную функциональность «из коробки». Из опенсорсных решений, позволяющих анализировать тесты на разных уровнях, стоит упомянуть ReportPortal и Allure Report. На примере последнего мы проанализируем, что нужно, для того, чтобы сделать тесты «читаемыми» для всей команды — а в конце покажем, как эту функциональность можно расширить, если вдруг под ваш уникальный стэк её не удалось найти.

Читаемость тестов достигается за счёт того, что демонстрируемые пользователю результаты не зависят от языка и фреймворка тестов. Такая независимость — результат изначального структурного решения, но для реализации этого решения потребовалось написать множество интеграций, в сумме на сотни тысяч строк кода.

В Allure заложено несколько механизмов, которые позволяют облегчить эту трудоёмкую задачу. Давайте представим, что мы пишем новую интеграцию, взглянем на ресурсы, которые система нам для этого предоставляет, и попробуем оценить трудозатраты.

Интеграция Selenide и Allure Report

Для начала сравним интеграцию allure-selenide с нативными отчётами Selenide и попробуем оценить объём работы, необходимый для создания того и другого.

Написать простой отчёт для Selenide довольно легко, но возможностей сделать его качественным мало. В JUnit есть только одна точка расширения — исключение, выбрасываемое при сбое теста. В это исключение можно вложить мета-информацию, но работать с ней будет неудобно.

По умолчанию Selenide и другие инструменты идут по простому пути: при сбое теста вы получаете текст исключения, скриншот и HTML-код страницы на момент сбоя.

Если вы единственный тестировщик в команде и хорошо помните свои тесты, этих данных может быть вполне достаточно — о чём нам и сообщают разработчики Selenide.

Без дополнительных плагинов отчёт Allure тоже будет содержать только текст исключения: 

Теперь попробуем активировать allure-selenide и allure-junit. Для корректной работы allure-selenide нужно добавить следующую строку в тест или в метод с аннотацией @BeforeAll:

SelenideLogger.addListener(«AllureSelenide», new AllureSelenide());

Теперь результаты тестов будут содержать пошаговую информацию, с указанием места сбоя, а также скриншоты и исходный код страницы:

Кроме того, теперь можно использовать функцию step() или аннотацию @Step для описания шагов на естественном языке — это делает отчёты понятными не только для программистов, но и для других участников команды.

Хотя добавление аннотаций может показаться трудозатратным, в перспективе это экономит время: вместо ответов на многочисленные вопросы о том, что делает тест, можно просто показать понятный отчёт.

Итак, allure-selenide предоставляет гораздо более мощный инструмент по сравнению с нативными отчётами Selenide (и большинства других инструментов). Сколько времени ушло на создание этой интеграции, включая тесты? Попробуем оценить исходный код с помощью инструмента scc:

Учитывая предоставляемую функциональность, 2.6 человеко-месяцев — очень разумная цифра. Скорее всего, столько же заняло бы предоставить то простое исключение, которое мы получаем с нативными отчётами Selenide. 

Один из ресурсов, позволяющих снизить трудоёмкость интеграции allure-selenide — это общие библиотеки Allure. Рассмотрим их работу и сложность написания.

Общие библиотеки

250 строк кода (исключая тесты) в allure-selenide обращаются к 500 строкам кода в allure-model и 1300 строкам в allure-java-commons (оба пакета входят в allure-java). Вот трудозатраты, которых потребовал allure-java-commons:

Изначально большинство адаптеров фреймворков для Allure писались независимо активными людьми из сообщества, которым понравился инструмент. Затем они были собраны в одном репозитории, и общие части кода были объединены в отдельные библиотеки.

Эта централизация значительно упростила написание новых интеграций. Сегодня существует около трех десятков интеграций для различных Java-фреймворков и инструментов — полный список можно найти здесь. Значительная часть этих интеграций размещены в allure-java и используют общие библиотеки.

Написание общих библиотек — непростая задача, поскольку в них решаются довольно сложные проблемы выполнения. Например, при работе над интеграцией allure-go Антон Синяев потратил несколько месяцев на решение проблемы параллельного выполнения тестов. На тот момент эта проблема была уже восемь лет известна (и не решена) в testify, фреймворке, ответвлением которого является allure-go. Такие проблемы бывают уникальными для фреймворков, что затрудняет написание общих библиотек.

Пакет allure-junit4 дает представление о том, сколько времени нужно на написание интеграции, когда процесс отработан и присутствуют общие библиотеки:

Без общих библиотек на эту функциональность пришлось бы потратить полгода.

JSON с результатами

Какие ресурсы помимо общих библиотек помогают при написании интеграции?

Предположим, мы пишем интеграцию с нуля для нового языка, такого как Go. Go очень отличается от Java или Python, как в базовых вещах, таких как отсутствие классов, так и в способе работы с потоками. Мало того, что невозможно переиспользовать код — даже общие решения нельзя перевести с одного языка на другой. Тогда что можно переиспользовать?

Даже если вы работаете с языком без классов (Go), вы можете использовать Allure благодаря формату JSON, который стал общей точкой соприкосновения для всех языков. Именно этот формат делает Allure Report независимым от языка.

Разработка этого формата данных заняла около года, и в него были включены важные архитектурные решения — а значит, когда вы пишете новую интеграцию, на эти решения силы тратить уже не нужно. Благодаря этому первую версию allure-go удалось написать за одни выходные — хоть после этого и пришлось потратить несколько месяцев на решение проблем выполнения и устранение неполадок.

Опыт

Наименее осязаемым ресурсом Allure является опыт. Написание интеграций — особая область программирования, и опытный в ней человек будет гораздо продуктивнее, чем просто талантливый разработчик.

Попробуем выразить это в цифрах. За 2–3 года можно переписать Allure с нуля, но только если у вас будет команда из 10+ человек, включая архитектора и инженеров по каждому языку. А ещё — люди, понимающие, зачем это вообще нужно.

Сообщество

Здесь мы приходим к последнему — и, возможно, наиболее важному — фактору. Сообщество Allure определило развитие инструмента следующими способами:

Спрос:

Как уже было сказано, на правильную реализацию отчётов могут уйти месяцы. Если вы создаёте отчёт исключительно для собственного удобства, вы, вероятно, сделаете работу наскоро. А если вы знаете, что миллионы людей будут пользоваться вашим инструментом, это будет достаточной мотивацией, чтобы посидеть дополнительный месяц или два и обеспечить, скажем, правильное параллельное выполнение тестов.

Опытные разработчики:

Поскольку у Allure открытый исходный код, в сообществе всегда было много талантливых разработчиков, пишущих интеграции. Многие из них в итоге примкнули к команде разработки Allure Report.

Сами интеграции:

В самом начале, на стадии Allure-1, авторы отчёта написали только один адаптер (для JUnit), а затем сосредоточилась на механизме. Но решение разделить адаптер и отчёт облегчило другим людям написание собственных адаптеров — и они это сделали, покрыв все важные языки и фреймворки. Впоследствие команда Allure Report проверила и объединила эти интеграции. Вот суммарная оценка этих объединённых усилий для одного языка (allure-java):

Эта работа оказалась возможной благодаря тому, что для многих разработчиков Allure Report стал инструментом по умолчанию. Именно они продолжают быть основой сообщества, предлагают новые идеи и следят за развитием инструмента.

Заключение

Структура Allure Report оформилась не сразу. Идея возникла 12 лет назад, годы ушли на оформление структуры, а за счёт диалога с сообществом развитие и планирование продолжается вплоть до сегодняшнего дня. Получившийся в итоге инструмент ориентирован на расширяемость и простоту создания новых интеграций. Любая работа в этой экосистеме сегодня опирается на накопленные годами код, опыт и архитектурные решения.

Благодаря тому, что Allure — опенсорсный продукт, вы можете сами написать свою интеграцию! Для этого есть все необходимые материалы:

• документация по JSON-формату Allure;

• готовые примеры из allure-java;

• открытое к вопросам и обсуждению сообщество.

Возможно, именно ваш вклад определит, каким будет Allure завтра.