@SlavikF, Дмитрий Баев - главный contributor. Он как раз основную часть репорта и переписывает. Но сервером вроде другие люди еще занимаются. Сам Дима несколько дней назад подтвердил в переписке, что сервер будет платным, но очень дешевым. Ну и собственно все находится на этапе беты.
Платным?? Ничосе!
Надеюсь не по корпоративным меркам дешёвый, а по пользовательским меркам дешёвый
Я б купил если будет стоит до 50$
Вот 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
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) {
}
Т.е. через точку мы можем проходиться по структуре сущностей, извлекая значения требуемых полей, заключенных в фигурные скобки.
П.С. Как будет время - обновлю доки.
А в 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
каким-то кастомным типом и добавить возможность задания имени элемента. Тогда доступ к нему будет осуществляться по выше указанной схеме.
Идею понял, спасибо
А интересует такой вопрос.
Allure 2.0 поддерживает русский язык в аннотациях?
У меня к сожалению вот такое выдает внутри отчета: Description
добрій вечер
Буду благодарен за помощь.
Должен поддерживаться. Писали то ребята из Яндекса. Хотя, уже и не работают там, но все же. Если есть проблемы с выводом, то проще завести issue на GitHub c детальными степами.
Спасибо за подсказку