Можно ли выводить логи Селенида в консоль по ходу выполнения теста?

Можно ли выводить логи Селенида в консоль по ходу выполнения теста? если да, то как это сделать?
имею в виду логи Селенида которые отображаются в аллюр отчете:
image

на проекте используется maven+java+selenide+testng+allure

Готовой фичи нет. Да и зачем?

Но сделать легко.
В том же месте, где у вас прописано
SelenideLogger.addListener("AllureSelenide", ...)

Нужно добавить аналогичный код, но своим листенером:

SelenideLogger.addListener("AllureSelenide", new SelenideStepsLogger());

Который внутри очень просто реализуется:

class SelenideStepsLogger implements LogEventListener {
  public void beforeEvent(com.codeborne.selenide.logevents.LogEvent logEvent) {}

  public void afterEvent(com.codeborne.selenide.logevents.LogEvent logEvent) {
    logger.info("Сделали то-то");
  }
}
2 симпатии

Спасибо Андрей!
сделал то что хотел)

Погоди-ка, но ведь про TextReport ты знаешь?

https://ru.selenide.org/documentation/reports.html

мм это немного не то что мне нужно)
в общем после прогона полного тест рана пользуемся Аллюр отчетом которого вполне хватает для всего
но еще захотелось видеть шаги по ходу выполнения теста в консоли IDE
не запаривайтесь сильно о том зачем оно мне :grinning: это сложилось исторически, да и мне как-то спокойнее и удобнее видеть пробегающие шаги в консоли когда нужно проранить один тест к примеру
Спасибо большое за помощь, ваш первый ответ был абсолютно о том что нужно было)

Понятно, это я и хотел уточнить.

Я ещё пытаюсь понять, может, это для всех полезная фича, и стоит её в селенид добавить.

1 симпатия

Вполне может быть полезной

Я неделю назад пытался отловить infinite loop с параллейным запуском
Логов по проекту крайне мало.
Чтобы стало понятно, на каком элементе было зацикливание, добавлял логирование в общие методы, которые переиспользуются в пейдж объектах

  • чтобы стало понятно какой элемент проверяется и какой condition

Благодаря тому, что 90% методов используют эти общие методы, зона поиска сузилась и отыскалась причина

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

Ух ты, как интересно. А как же вообще получилось сделать бесконечный цикл в тестах?

Где-то рекурсионный метод, где-то while цикл)

Например, кликать на кнопку следующей страницы до тех пор пока кол-во элементов на странице не N или пока делать пока аттрибут не поменяет свое значение + catch блоки без логов или ошибок

Одна из основных причин самом деле в тестируемом продукте

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

Ну и конечно качество кода автоматизации
Я осознаю масштабы появления этих проблем:

  1. ненужные FindBy
  2. локаторы
  3. где-то устаревший Page.On (убрал довольно легко использовал Selenide.page())
  4. много дублирования кода
  5. if-else методы и заглушки
  6. Ненужные TestNG ассерты
    список большой.
    В маленьком масштабе это легко исправлять, но в большом масштабе тут добавляются нетипичные челенджи - убеждать ребят, что KISS и DRY это пушка, или почему им не стоит писать так, почему тернарные операции и Stream.API это то, что нам нужно и не нужно быть кодером просто… в добавок попробуй объяснить + убедить + и наконец-то увлечь ребят, чтобы они писали хорошую базовую автоматизацию, а не продолжали писать как и год назад

Есть где-то может клуб анонимных автоматизаторов, которые борються с этим каждый день ? =)

Да их навалом.
Собственно, этот сайт и есть такой клуб.
Есть ещё чатики в телеграме и слаке.