Allure 2.0 - нововведения / грядущие изменения

Наверное, многие уже в курсе того, что Allure полностью переписывается на Java 8. Следующим релизом будет версия 2.0, в которую войдет множество новых фич. Официальных дат пока нет. Но наиболее любопытные могут уже сейчас пощупать новую версию, а также - отслеживать статус по RoadMap.

Функционал конечно еще сыроват, но некоторые нововведения уже есть возможность лицезреть. Ниже будет приведен список того, что удалось вытянуть из текущего снепшота.

На странице Overview дефекты разбиты на Product / Test. По всей видимости, идея заключается в их фильтрации по failed on asserts vs failed on unhandled exceptions.

Включены все баг фиксы / фичи актуальной на текущий момент версии 1.4.23.RC3. К примеру, отображение двух знаков после точки на диаграмме статуса (проблема округления):

В таймлайне дополнительно отображаются секунды:

Переработана система фильтрации по статусу. Новые фильтры доступны как на Behaviors странице, так и на xUnit.

Гриды заменены на древовидную структуру. Вот так, к примеру, выглядит Behaviors с вложенными сторями. При этом, статусы отображаются рядом с именами тестов в виде разноцветных кружков.

Добавилась долгожданная пейджа со структурой тестов:

Естественно, все кликабельно.
Немного видоизменилась панель теста:

Убрали тайм снепшоты из степов, зато добавили информацию о старте / финише и продолжительности.

Все так же можно атачить video и uri.

Как я уже отметил, репорт еще сыроват, потому есть и кое-какие баги.

В плане сборки, многие модули были выкинуты, включая bundle. Посему, новая версия будет собираться исключительно при помощи commandline модуля. Если я правильно понял, maven-plugin для генерации репорта уже не будет саппортиться.

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

Стоит также отметить, что Allure 2.0 будет полностью совместим с текущей версией. Старые адаптеры будут работать. Фактически вы уже сейчас можете натравить новый генератор на результаты, сформированные актуальной версией. Хотя, пока не совсем понятны изменения в модели, т.к. кое-какие проперти попросту отсутствуют в новой версии.

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

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

11 лайков

Не в курсе, планируется ли разработка нового адаптера (или переделка существующего) под NUnit? Существующий адаптер обладает рябом неудобств в запуске + отсутствует какая-либо поддержка нового функционала Allure.

К сожалению, есть ограничение в выборе языка написания автотестов (только C#), поэтому вариант использовать Allure “как все нормальные люди” исключен.

Соболезную =(
Попробуйте написать адаптер сами - убьете двух зайцев (нужный адаптер + прокачка скиллов c#)

Думаю об этом. К сожалению C# - не мой основной язык, и я все еще вникаю в его премудрости. Вполне возможно попробую позаниматься по вечерам в качестве pet-проекта, но со временем пока напряг. Посмотрим, что из этого выйдет.

Написал на почту указанную на страничке Allure, дождусь ответа, а потом уже подумаю, что делать дальше

Главные разработчики Allure - джависты, так что все адаптеры для других языков саппортятся силами коммьюнити. Если никто не занимается nUnit adaptor’ом, видимо, всех все устраивает, или процент использующих Allure для .net - ничтожно мал. Открою секрет: даже testng-adaptor не будет включен в официальный репозиторий Allure 2.0. Главный contributor уже создал issue в testng-community, делегировав maintain данного адаптера сообществу.

Но если заглянуть в исходники того же testng-adaptor’а, можно обнаружить один единственный класс, который занимается сбором всей необходимой информации. Так что не думаю, что у кого-либо возникнут проблемы с его саппортом. Подозреваю, что для .net аналогичная ситуация. Вопрос в желании скорее.

Помимо всего прочего, как я уже отметил в изначальном посте, во второй версии будет работать система плагинов. А это значит, что любой желающий сможет писать свои собственные кастомные фичи, включая особенности работы различных unit frameworks.

Спасибо, буду следить за обновлениями. И, может, попробую свои силы с адаптером под .net

Про Allure сервер интересно.
Вот тут, некто господин ‘baev’ обещал что-то похожее выложить в опен соурc:
Видимо, не сложилось. Будут хотеть денежку…

@SlavikF, Дмитрий Баев - главный contributor. Он как раз основную часть репорта и переписывает. Но сервером вроде другие люди еще занимаются. Сам Дима несколько дней назад подтвердил в переписке, что сервер будет платным, но очень дешевым. Ну и собственно все находится на этапе беты.

Платным?? Ничосе!

Надеюсь не по корпоративным меркам дешёвый, а по пользовательским меркам дешёвый

Я б купил если будет стоит до 50$

1 лайк

Вот EPAM выкатили конкурента - Report Portal.
Есть какой-нибудь прогресс у Yandex с Алюр сервером?

Вот здесь вот вроде бы показывается milestone для Allure 2:

А вот здесь вроде уже вышел релиз для Allure 2:

Но про Allure server ничего не нашёл. То есть в опен соурс его выпускать не планируют?

я так понял пока только есть инструкция как с gradle аго интегрировать ? А что на счет maven плагина ?

Allure 2 уже релизнулся, да. Сервера в open-source не будет. Уже не раз об этом говорили. Точная дата выпуска пока не известна (изначально говорили о мае, но это маловероятно), ибо разработчики пустили все ресурсы на выпуск репорта.

П.С. И к слову, Allure и ReportPortal сложно в принципе назвать конкурентами. На текущий момент они решают совершенно разные проблемы.

Ну для testng конфигурация в доках есть под maven. В другой теме ведь линк постил.
А если речь о генерации репорта, то maven-plugin пока не обновили. Он еще не поддерживает новую версию. Но jenkins plugin то рабочий. А локально все делается очень просто:

allure serve /allure-results-folder
1 лайк

thnx

Allure и ReportPortal сложно в принципе назвать конкурентами. На текущий момент они решают совершенно разные проблемы.

Согласен.

Но вот Allure Server - это как раз планируется, как аналог / конкурент ReportPortal. Верно?

В целом, да. Но у меня пока мало информации относительно фич сервера. Вроде как разработчики планируют сделать полноценную поддержку истории запусков, прямую интеграцию с issue management systems (для мгновенного создания багов без доп. переходов), ручную категоризацию дефектов, редирект в код по стеку и т.п.

Кстати, только что пересмотрел доки по TestNG. Там не совсем актуальная информация по степам. Изначально в качестве tmp решения разработчики добавили автоматическую вставку аргументов из сигнатуры метода, полностью выпилив предыдущий механизм с плейсхолдерами.

Немного пообщавшись с ними насчет usability и их видения этой функциональности, был предложен следующий PR.

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

Положим, у нас есть некий юзер:

@Getter
@RequiredArgsConstructor
public class DummyUser {

    private final DummyEmail[] emails;
    private final String password;
    private final DummyCard card;
}

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

@Step("\"{user.emails.address}\", \"{user.emails}\", \"{user.emails.attachments}\", \"{user.password}\", \"{}\"," +
       " \"{user.card.number}\", \"{missing}\", {staySignedIn}")
private void loginWith(final DummyUser user, final boolean staySignedIn) {
}

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

П.С. Как будет время - обновлю доки.

2 лайка

А в JUnit такое также ​будет работать?

Это сделано на уровне commons модуля. Так что должно.

Может немного глупый вопрос, но все же - а в первой версии такой фичи нет?