Automation Remarks

В этой заметке я опишу свои впечатления от использования Report Portal - опенсорс проекта, который призван облегчить жизнь автоматизаторов.

Что такое репорт портал?

Смотрим, что говорят разработчики в документации:

Report Portal is a service, it provides great capabilities for speeding up results
analysis and reporting by means of built-in analytical features.
Report Portal is the great addition to the
Continuous Integration and Continuous Testing process.
It seamlessly integrates with mainstream platforms such as Jenkins, Jira,
BDD process, majority of Functional and Unit testing frameworks.
Real-time integration allows to manage and track execution status directly from Report Portal.

Сервис, который ускоряет анализ результатов прогона автоматических тестов и предоставляет возможность репортинга. Звучит достаточно полезно. Может интегрироваться со всеми мейнстримными тулами и xUnit фреймворками - тоже многообещающе.

Зачем я вообще на него смотрел?

О репорт портале я слышал еще до того, как это стало мейнстримом. В сентябре 2016 года я пробовал запустить одну из первых версий, вышедных в open-source. Тогда мне не понравилось то, что портал потребляет очень много ресурсов (>8GB RAM), да и интеграция с TestNG и Junit не выглядела так легко. Тогда я потратил примерно час, чтобы все поднять.

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

Что из этого получилось? Давайте смотреть.

Установка:

Здесь все достаточно неплохо.

Берем докер, делаем docker-compose up, ждем пару минут и сервис благополучно поднимается. Это, конечно, большой плюс. По этому пункту замечаний нет.

Интеграция с xUnit фреймворками:

Сначала я решил подключить портал к одному из проектов, написанных на Python + Pytest. В официальном репозитории есть соответсутвующий агент, в котором сказано сделать следующее:

pip install pytest-reportportal

Не взлетело - завел баг. Такое поведение сразу отталкивает, но так как желание попробовать было выше обычного, я поставил его через Github:

pip install git+https://github.com/reportportal/agent-python-pytest.git

Дальше нужно создать pytest.ini файл:

[pytest]
mandatory fields
rp_uuid = uid reportportal
rp_endpoint = http://ip:port
rp_project = Project of ReportPortal

Вот тут у меня есть замечание: в документации "очень мелким шрифтом" прописано, куда нужно пойти и взять эти вот значения. Это указано в документации к модулю для TestNG. Такой вот момент.

Ну да ладно, давайте попробуем запустить тесты:

py.test ./tests --rp-launch selene_blog_test

Все классно: тесты пробегают, в портале создаются соответствующие записи.

Однако, есть досадные минусы, которые пока что делают интеграцию портала с pytest практически бессмысленным занятием. Для упавших тестов нету ни стектрейса, ни причины падения. И это расходится со словами "provides great capabilities for speeding up results analysis".

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

Мой вывод: пока что Report Portal для пайтон проектов бесполезен по причинам, указанным выше. Имея Jenkins и Allure, мы получаем всю нужную информацию без каких-либо накладных расходов.

Затем я решил настроить Report Portal + TestNG.

Весь процесс занял у меня 30 минут. В документации нету примера интеграции для проектов на Gradle. Из-за этого мне пришлось потратить определенное время на то, чтобы разобраться.

Ниже описание build.gradle файла с настройками:

apply plugin: 'java'

repositories {
    jcenter()
    maven {
        url  "http://dl.bintray.com/epam/reportportal"
    }
}

dependencies {
    compile 'com.epam.reportportal:agent-java-testng:3.0.0'
    compile 'com.epam.reportportal:logger-java-logback:2.6.0'
    compile 'com.epam.reportportal:logger-java-log4j:2.6.1'
    compile group: 'org.testng', name: 'testng', version: '6.11'
}

test {
    useTestNG()
}

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

Из хорошего:

Портал работает достаточно шустро;
Красивый интерфейс;
Есть возможность настроить информативные графики и фильтры.

Что имеем в итоге:

Шероховатости заметны. Да, это опенсорс, но все же хотелось бы иметь plug&play. Когда смотришь на презентации и скринкасты, все выглядит, как новый майбах… но салон местами как у новой девятки =) На данный момент более предпочтительной я считаю связку Jenkins + Allure. Степень красивости, возможно, ниже, но информативность и легковесность выше.

Киллер-фичей Report Portal является алгоритм, который умеет автоматически анализировать результаты фейлов и маркать их как баг/ не баг. Секунду! Allure умеет это делать еще с первых дней. Более того, для правильно построенной системы автоматизации время на разбор занимает пару минут, так как на своих проектах я предпочитаю принцип Zero failed tests. У нас не очень большой проект: суммарный объем тестов, которые пишут автоматизаторы, до 200. Мы стараемся всегда держать тесты зелеными и любой фейл становится причиной разбирательств. Именно поэтому такая штука, как репорт портал, нам не нужна.

Кому может пригодиться Report Portal?

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

Вот такие впечатления от Report Portal. Если вы уже успели его попробовать или успешно внедрили, пишите в комментариях - будем обсуждать и давать фидбек разработчикам. Ведь опенсорс успешным делает только комьюнити. В следующий раз в вам расскажу об инструменте Selenoid, но это уже будет совсем другая история. Па-па =)

Підписатися:

Схожі статті:

Вечір бруду 2023

Не баг, а фіча #5

Не баг, а фіча #4

Зустрічайте новий подкаст - Не баг, а фіча!