t.me/atinfo_chat Telegram группа по автоматизации тестирования

Подсистема контроля событий тестового фреймворка

Теги: #<Tag:0x00007f7484d60ee8> #<Tag:0x00007f7484d60d58> #<Tag:0x00007f7484d60c68> #<Tag:0x00007f7484d60b78> #<Tag:0x00007f7484d60a10> #<Tag:0x00007f7484d60858>

Доброго времени суток, форумчане!

У меня сложилась следующая ситуация:
В фреймворке реализован подход PageObject (в том виде, как я его понимаю :slight_smile: ), а именно имеется 3 уровня - Test -> Steps -> Page.
В качестве инструментов использую Java, Selenide,Allure.
Сложилась ситуация, когда на уровне “Step” (методы анатированные @Step) в описанных шагах или проверках (Assert) возможны 2 варианта: 1 - все выполняется удачно; 2 - степ/ассерт падает (AssertionError).
Для обычных степов применена “проброска” ошибки, которая наследована от AssertionError. т.е. если метод описанный в степе “ломается”, то он бросает ExtendetAssertionError, который в момент “полета”, если заранее были переданы параметры, делает скриншот или аттачит текст/файл.
Труднее обстоит дело со степами, в которых делается Assert. Для реализации двух указанных выше возможных вариантов, пришлось каждый Assert обернуть в try/catch и конкретно указать что я хочу (аттач файла/скрина/текста).
Описанная выше конструкция хоть и доказала свою жизнепригодность (хотя бы в рамках тех задач, что приходилось мне решать) но, на мой взгляд, является довольно громоздкой и примитивной. На данном етапе я пытаюсь изучить что-то новое и реализовать описанный механизм более гибче о корректнее.
К примеру, по аналогии с thucydides, где ты не задумываешся о том, как пройдет степ (положительно или упадет), а просто описываеш все нужное, а при падении или удачном прохождении скриншоты делаются автоматически.
Где то интуитивно понимаю, что нужно поработать с так называемыми “листнерми”, но ничего толкового, в плане информации, найти не могу.

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

Забудьте про ассерты на уровне пейджей. Это архитектурно неверно. Проверки должны осуществляться исключительно на уровне тестов, либо при помощи специализированных оберток, направленных на верификацию (но вызываться они будут тоже в тестах).

Т.к. вы используете Selenide, тут вам прямиком к @asolntsev c вопросами. Насколько я знаю, там используется JUnit. Я могу лишь дать конкретные советы по слушателям TestNG.

В случае, если используются мягкие ассерты, идея довольно проста (TestNG):

  • подключается слушатель с интерфейсом, у которого переопределяется метод afterInvocation;
  • внутри метода проверяем, действительно ли “раздражителем” является тест, а не метод с другими специализированными аннотациями юнит фреймворка;
  • если все же это был тест, вызываем assertAll, который выплюнет AssertionError со списком всех зафейлившихся верификаций;
  • здесь же его обрабатываем и вручную маркируем тест, как failed (иначе весь execution будет прерван).

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

Моя первая реакция: это очередная иллюстрация того, что все эти степы и репорты только заморачивают людям головы и не приносят реальной пользы. Пишите простые тесты. При падении теста Selenide по-любому сделает скриншот. Путь к нему будет виден в стандартном отчёте JUnit. Этого достаточно для изучения ошибки. Больше ничего и не нужно.

@ArtOfLife Selenide можно использовать и с JUnit, и с TestNG, и с любым другим тестовым фреймворком. И даже на любом JVM-языке.

Очередной раз видна небольшая путаница с пониманием того, для чего фреймворки определенные нужны. Selenide - это селениум обертка, ей всё равно, что над ней - junit, testNg, можно хоть из main запускать.
Allure - это просто отчеты, ей всё равно, selenium, junit, даже язык(есть куча адаптеров).

Живой пример - Thucydies (такая же обертка над selenium), который не имеет поддержки TestNG. У него свой раннер.

Я указал, про какие я говорю :smile:
А фукидид - это вообще отдельный разговор :smile:

Слушайте, а изначальная проблема-то решена? Автор вопроса, мы вам вообще хоть как-то помогли?

Честно говоря, пока полезной идеи для себя не нашел. Возможно я не совсем корректно объяснил что именно ищу, попробую конкретизировать и объяснить на примере Thucydies.

Я нахожу очень удобным то, что все выполняемое в методах аннотированными @Step при некорректном результате (с точки зрения логики теста) будет:

  1. Автоматически помечено как проваленный степ и, как следствие, иметь соответствующее отображение в отчете;
  2. Прикреплен скриншот.
    Самое привлекательное, то, что в случае с Thucydies я не замарачиваюсь с описанием каждого конкретного случая успешного/провального теста. Есть просто @Step который сам “разберется” как, что и куда прикреплять и как помечать в обоих случаях (успех/провал).

В Allure есть возможность прикрепить не только скриншот, но также файл, строку и т.д…
Вот простенький пример моего степа:

 @Step
 public void logInAccount {
	dictionaryPage.goTo("http://www.ya.ru");
	dictionaryPage.clickOnLogInButton();
	dictionaryPage.enterEmail("vasya");
	dictionaryPage.enterPass("123");
	Assert.assertTrue("You did't enter to account successfully!", getUserName.equals("vasya"));
	makeScreenShoot();
        attachFaile("bla-bla-filieName");
}

Если все хорошо, то в конце степа я получу скриншот и файл которые прикрепятся к отчету Allure.
Что будет если один из методов степа упадет? Он кинет ексепшн, который я унаследовал от AssertError и в котором уже прописал методы makeScreenShoot() и attachFaile().

Как поступить с Assert.assertTrue("You did't enter to account successfully!", getUserName.equals("vasya"));? Видь ассертов оч много и не как не знаешь какой буш использовать в следующем тесте, а переопределять все, ну тож не прально.

Я выкрутился так:

 @Step
 public void logInAccount {
   dictionaryPage.goTo("http://www.ya.ru");
   dictionaryPage.clickOnLogInButton();
   dictionaryPage.enterEmail("vasya");
   dictionaryPage.enterPass("123");
 try {
         Assert.assertTrue("You did't enter to account successfully!", getUserName.equals("vasya"));
         makeScreenShoot();
         attachFaile();
         } catch (AssertionError e){
           makeScreenShoot();
           attachFaile("bla-bla-filieName")
           throw e;
        }
}

Работает ли етот механизм? Да, свою функцию выполняет отлично. Но, я прекрасно понимаю что ето довольно костыльно и хочу отойти от “обертываения” оссертов try/catch. Конечной целью является конструкция из первого примера где бы скриншот и прикрепление файла произошло и в случае падения Assert-a.

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

Все прекрасно поняли, что вам нужно еще в первом посте. Возможно вы не совсем внимательно прочитали то, что вам ответили выше? Все решения находятся под носом. Достаточно лишь заглянуть на GitHub Selenide / Allure, где собрано множество примеров с готовыми тестами.

2 Симпатий

Благодарю! Пошел “копать”!

Чтобы не слишком много копать, предлагаю сделать всё намного проще. Попробуйте написать тесты только на Selenide, без всяких степов и отчётов. Это очень быстро и просто. И очень вероятно, что этого достаточно!
При падениях Selenide будет автоматом делать скриншоты, и они попадут в стандартный отчёт, генерируемый мавеном (или любым другим раннером, который вы используете). Всё! Больше ничего и не нужно.

Спасибо за совет, но уже сформировалась некая структура которая отлично ужилась с Allure. На выходе получаю красивый отчет не только со скриншотами но и файлами, что очень удобно.
А попытка уйти от try/cath - ето, так сказать, движение вперед, что бы не застаиваться на достигнутом. Хотя, по предварительной оценки объема информации, которую нужно проработать, с наскока и за пару часов решить етот вопрос мне не удастся… А может ето и к лучшему, в большем разберусь :).