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

программирование java
, , , , ,
#1

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

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

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

#2

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

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

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

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

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

#3

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

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

#4

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

#5

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

#6

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

#7

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

#8

Честно говоря, пока полезной идеи для себя не нашел. Возможно я не совсем корректно объяснил что именно ищу, попробую конкретизировать и объяснить на примере 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.

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

#9

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

2 лайка
#10

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

#11

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

#12

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