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

@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 модуля. Так что должно.

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

Нет, в первой версии плейсхолдеры работают по индексам:

@Step("Type {0} into username field, {1} into password field.")
public LoginPage loginWith(final String username, final String password) {
}

А если передать кастомный тип:

@Step("Login with {0}.")
public LoginPage loginWith(final User user) {
}

для вывода полей определенной вложенности, надо особым образом переопределять toString(), игнорируя лишний шум:

public String toString() {
    return "[username=" + getUsername() + 
           ", password=" + getPassword() + "]";
}

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

@Step("Login with {user.username} / {user.password}.")
public LoginPage loginWith(final User user) {
}

Спасибо, за развернутый ответ.
Могу создать отдельную тему, но спрошу пока в пределах этой.

Могу ли я вытянуть не значение требуемого поля, а название этой переменной. К примеру, если у меня есть переменная

private By loginButtonLocator = By.cssSelector("#login");

и я хочу, чтобы в отчете отображалось не значение #login, а loginButtonLocator. Такое возможно?

Нет, т.к. по-умолчанию работа с аргументами ведется на уровне значений, а не имен. В целом, это возможно при использовании AOP. Но с точки зрения технической реализации такой подход оставляет больше вопросов, чем ответов. Как понять, что пользователь хочет извлечь именно имя, а не значение? Разве что добавить какие-то зарезервированные keywords. Но что, если они совпадут с названиями полей класса? Проще уже с клиентской стороны обернуть By каким-то кастомным типом и добавить возможность задания имени элемента. Тогда доступ к нему будет осуществляться по выше указанной схеме.

1 лайк

Идею понял, спасибо

А интересует такой вопрос.
Allure 2.0 поддерживает русский язык в аннотациях?
У меня к сожалению вот такое выдает внутри отчета: Description

добрій вечер
Буду благодарен за помощь.

Должен поддерживаться. Писали то ребята из Яндекса. Хотя, уже и не работают там, но все же. Если есть проблемы с выводом, то проще завести issue на GitHub c детальными степами.

Спасибо за подсказку