Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Используем и кастомизируем spock-reports для создания гибких отчетов

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Привет! Я — Сергей Могилевский, QA Engineer и QA Lead в NIX, спикер NIXMultiConf.

Допустим, ты попал в новый проект, где нужно автоматизировать тестирование. А, может, другая команда передала уже настроенную автоматизацию, и ее надо поддерживать. В любом случае ты можешь столкнуться с фреймворком spock. В работе с ним было бы неплохо комфортно читать результаты своих тестов и репортить их проектному менеджеру. Хорошая новость — у spock есть практически нативное решение для генерации репортов spock-reports.

В этой статье разберем, как подключить spock-reports к проекту (спойлер: это очень просто), и рассмотрим примеры кастомизации репорта под разные специфичные запросы и цели.

Что такое spock-reports

Spock-reports — это отчет из разряда «‎‎лучше так, чем вообще ничего». Выглядит не особо красиво и «‎‎из коробки» показывает всю информацию, но ничего более. Сразу же после подключения библиотеки и прогонки тестов с использованием spock в папке с проектом генерируется html-отчет. Его можно открыть и просмотреть в любом удобном тебе браузере. При открытии файла index.html видим сводку по результатам тестов, которые запускали (примеры взяты из документации).

Кликнув на названия тестовых классов в таблице, можно увидеть развернутый результат по каждому тесту в этом классе.

Отсюда можно легко понять, какие конкретно тесты упали и почему, а какие — прошли удачно, а также ознакомиться с приложенной ошибкой. Вообще spock довольно неплохо дает понять, почему валятся ассершены.

Как добавить spock-reports в проект

Как я и обещал, здесь все очень просто. Чтобы отчеты начали генерироваться, достаточно добавить несколько строчек в build.gradle файл для градла или pom.xml для мавена, соответственно:

Для Maven:

<dependency>
  <groupId>com.athaydes</groupId>
  <artifactId>spock-reports</artifactId>
  <version>2.0.1-RC3</version>
  <scope>test</scope>
  <!-- this avoids affecting your version of Groovy/Spock -->
  <exclusions>
    <exclusion>
      <groupId>*</groupId>
      <artifactId>*</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.7.30</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-simple</artifactId>
  <version>1.7.30</version>
  <scope>test</scope>
</dependency>

Для Gradle:

repositories {
  jcenter()
}

dependencies {
    testImplementation( 'com.athaydes:spock-reports:2.0.1-RC3' ) {
        transitive = false    }
    testImplementation 'org.slf4j:slf4j-api:1.7.30'
    testRuntimeClasspath 'org.slf4j:slf4j-simple:1.7.30'
}

А если базовой версии отчета не хватает и хочется чего-то большего?

Кастомизация

Базовые изменения

Spock-reports дает пользователю возможность изменять отчеты через properties-файл. Таким образом, к примеру, можно подменить css-файл со стилями для index.html страницы или отдельных страниц для тестовых классов.

Чтобы это сработало нужно создать com.athaydes.spockframework.report.IReportCreator.properties файл в директории test/groovy/resources/META-INF/services/

И добавить в него такие строки:

com.athaydes.spockframework.report.internal.HtmlReportCreator.featureReportCss=custom-feature-report.css
com.athaydes.spockframework.report.internal.HtmlReportCreator.summaryReportCss=custom-summary-report.css

Теперь при следующем запуске тестов и генерации отчета файлы стилей подтянутся из указанных файлов (custom-feature-report.css и custom-summary-report.css). Другие варианты встроенных кастомизаций описаны в README файле spock-reports на Github. Но что, если их не достаточно?

Глубокая кастомизация с заменой классов spock-reports

В таком случае есть еще один вариант проперти, которая может стать настоящим game changer. В тот же properties-файл добавляем строку:

com.athaydes.spockframework.report.IReportCreator=customization.CustomizedHtmlReportCreator

Естественно, заменяем customization.CustomizedHtmlReportCreator на реальный путь к классу, который должен сменить стандартный класс HtmlReportCreator в spock-reports.

Как это работает? Сборка отчетов закреплена за одним классом в библиотеке — HtmlReportCreator. Разработчики оставили юзерам возможность подменить имплементацию этого класса на кастомную при инициализации сборки отчета. Подкинув свой класс HtmlReportCreator в spock-reports, в отчете можно менять практически что-угодно.

Проще всего начать кастомизировать репорты, скопировав оригинальную имплементацию HtmlReportCreator, и уже в ней вносить изменения.

Со следующими примерами могут возникнуть трудности в понимании структуры проекта и методов без самого проекта перед глазами. Все, что описано ниже, можно склонировать из этого репозитория, открыть в IntellijIDEA и посмотреть вживую.

Давайте проверим, используется ли вообще наш новосозданный класс. Для этого внесем какую-нибудь незначительную правку. Например, изменим стандартный текст. Заменим метод protected String reportHeader (SpecData data) так, чтобы он писал в отчет не «Report for ${Utils.getSpecClassName( data )}», а «Custom report for ${Utils.getSpecClassName( data )}».

Получиться должно вот так:

Перезапускаем тест, ждем сборки проекта и проверяем отчет. Текст должен измениться на страничке каждого класса. Так и получилось!

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

Кастомизация еще глубже

Оказывается, отчет генерируют несколько классов. Что же делать, если хочется внести изменения в какую-то часть отчета, которую изначально генерирует не HtmlReportCreator? Легко! Делаем замену другим классам и подкидываем их как импорт в тот же HtmlReportCreator (точнее в его копию). При попытке обратиться к методам других классов-генераторов библиотека будет попадать в наши измененные классы. Подобным способом можно заменить практически любой импорт из класса HtmlReportCreator, в том числе:

  • AbstractHtmlCreator
  • HtmlReportAggregator
  • ProblemBlockWriter
  • Utils и другие.

В качестве простого примера изменим что-то на главной странице отчета, которую пользователь видит во время открытия. Если взглянуть на исходники spock-reports, увидим, что эту часть отчета генерирует класс HtmlReportAggregator. Значит, это и есть наша цель! Создаем новый класс HtmlReportAggregator рядом с CustomizedHtmlReportCreator и копируем в него наполнение оригинального HtmlReportAggregator. Должно выглядеть так:

Затем идем в CustomizedHtmlReportCreator и убираем import для HtmlReportAggregator. Наша подмена лежит в том же «‎‎пакете», поэтому она подтянется автоматически. Теперь переходим HtmlReportAggregator и меняем там заглавный текст:

Снова перезапускаем тест и смотрим результат.

Измененный текст отображается в заголовке index.html страницы. И снова очередная победа!

Что дальше?

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

Возможности кастомизации практически безграничны. Можно добавить в отчет поддержку мануальных тест-кейсов по примеру serenity отчетов, изменить подсчет статистики или добавить графики и изображения. Осталось только понять, что понадобится в конкретном проекте.

P.S. О том, не проще ли в этом случае использовать Allure, можем пообщаться в комментариях :)

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі