Эффективные UI-тесты на Selenide

[asm0dey]

Обзор хороший, но первый пример теста, ИМХО, ужасны. Если тесты писать так — получится гигантская лапша в каждом тесте. Потому что если нам нужно протестировать функциональность гугла — мы в каждом етсте будем вынуждены открывать его страницу, что-то делать, проверять, опять делать… Нужен какой-то BDD типа Cucumber.

Кроме того очень не хватает обзора PageObject'ов, которые с Selenide делать очень просто.

[asolntsev]

Ох, плохие практики настолько прочно вошли в нашу жизнь, что уже кажутся хорошими. :(

Интерфейс (т.е. UI) поиска гугла, как известно, крайне простой. Для тестирования UI больше тестов не нужно.
Вот этого одного теста достаточно.

BDD вообще-то нужно для того, чтобы с заказчиком проговаривать бизнес-требования и записывать в виде тестов. В данном случае требований немного и они все в тесте уже отражены. Вы, видимо, имеете в виду, что понадобится много тестов для тестирования нюансов поиска — но это нужно тестировать не через UI. Там обязательно надо использовать модульные и интеграционные тесты, а вовсе не BDD и не Cucumber.

А про PageObject надо добавить, спаисбо.

[asm0dey]

Хм, я бы поспорил. На самом деле если вы тестируете гугл — вы ещё будете наверное несколько вещей проверять. Например что по ходу ввода вываливаются подсказки. Сколько блоков AdWords есть на странице. Что при поиске знаменитостей вываливается карточка с краткой информацией. Аналогично при поиске георафических единиц. Что до того как мы начали искать мы видим две кнопки для поиска. Что результаты поиска отличаются когда мы залогинены и когда нет (ладно, это спорно, согласен). Это всё нюансы интерфейса.

А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.

[asolntsev]

Согласен, функциональности там действительно значительно больше, чем мне казалось. Наверное, я никогда не искал знаменитостей. :)
Но изначальное утверждение, что первый тест ужасен — категорически не могу принять. Я могу написать качественные тесты на все перечисленные функции безо всякого BDD.

> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.

А кто же вам мешает любые другие тесты писать так, чтобы было понятно?
А кто вам мешает любой код делать самодокументирующимся?
Почему для этого непременно нужен какой-то там магический BDD? Без BDD никак, а возьми BDD — и оно само вдруг получится? Ага.

[asm0dey]

Он сделает написание самодокументирующегося кода проще, а код структурированнее. Более того, BDD-фреймворки дают возмоность простыми словами, насколько угодно длинно описать каждый сценарий, юезрстори и степ. В джаве, увы, у вас не может быть, например, пробелов в названии метода. И это автоматически значит что вам придётся эти названия методов расшифровывать.

Насчёт того, что вы можете написать качественные тесты — я, в общем-то, не сомневаюсь. Вопрос в том, сколько будет стоить поддержка этого дела. Так-то вообще все тесты чего угодно можно загнать в один метод и сказать, что так всё просто и понятно.

Но конечно же всё что я написал можно сделать и без BDD, просто сложнее. Можно Allure приделать, например, который даст методам нормальные дескрипшны, к TestNG который даёт зависимости методов друг от друга.

[aparamonov]

Для меня ваш cucumber — это огромная пушка, цель которой предоставить аналитикам самим писать тесты.
Это дополнительный уровень инфраструктуры в вашем коде. Имхо, проще добавить groovy/scala в проект в тесты и наслаждаться: etorreborre.github.io/specs2

Более того, cucumber тесты тупо дольше писать — надо писать именно те фразы, которые были определены для конкретного действия: github.com/cucumber/cucumber-jvm/blob/master/examples/java-calculator/src/test/java/cucumber/examples/java/calculator/RpnCalculatorStepdefs.java — ну почему я должен написать 'I add 1 and 2' и реализацию метода вместо простого calc.push(1).add(2) (предположение как выглядел бы вменяемый интерфейс к калькулятору)? Вместо одной строчки!

Это Вам кажется, что сложнее, потому что Вы не пробовали. Попробуете писать на обычных тест-фреймворках — у вас код будет лаконичнее и тестов, и самого тестируемого кода.

[asm0dey]

Извините, я не буду дальше спорить — мы как-то ни о чём спорим. Я пробовал тестировать по всякому. Я знаю людей, которые считают что Selenide — наколеночное поделие по сравнению с Serenity. Сам я начинал когда-то с JUnit + Selenium. И до Cucumber + Selenide я дошёл эволюционным путём.

[LionAlex]

> На самом деле если вы тестируете гугл — вы ещё будете наверное несколько вещей проверять.
Только это будет уже другие тесты.

> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
Фигня это все. Этот недоанглийский подходит только для очень простых вещей, которые легко читаются и без него. Правильное использование PageObject'ов с легкостью заменяет весь этот модный BDD.

[asm0dey]

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

[LMnet]

Если коротко, в Selenide каждый метод умеет немножко подождать, если надо. Люди называют это «умными ожиданиями».

Правильно я понимаю, что это должно полностью избавить от проблем со stale element reference exception? И каким образом реализовано это умное ожидание?

[asolntsev]

Да, это должно избавить от проблем со stale element exception в большинстве случаев. Совсем полностью невозможно даже теоретически. Всегда можно написать приложение и тест, который выкинет stale element, как ни старайся.

[asolntsev]

А реализовано «умное ожидание» очень просто:

while (прошло меньше 4 секунд) {
  try {
    element.doOperation();
  }
  catch (WebDriverException e) {
    sleep(10);
  }
}