Comments 12
Обзор хороший, но первый пример теста, ИМХО, ужасны. Если тесты писать так — получится гигантская лапша в каждом тесте. Потому что если нам нужно протестировать функциональность гугла — мы в каждом етсте будем вынуждены открывать его страницу, что-то делать, проверять, опять делать… Нужен какой-то BDD типа Cucumber.
Кроме того очень не хватает обзора PageObject'ов, которые с Selenide делать очень просто.
Кроме того очень не хватает обзора PageObject'ов, которые с Selenide делать очень просто.
Ох, плохие практики настолько прочно вошли в нашу жизнь, что уже кажутся хорошими. :(
Интерфейс (т.е. UI) поиска гугла, как известно, крайне простой. Для тестирования UI больше тестов не нужно.
Вот этого одного теста достаточно.
BDD вообще-то нужно для того, чтобы с заказчиком проговаривать бизнес-требования и записывать в виде тестов. В данном случае требований немного и они все в тесте уже отражены. Вы, видимо, имеете в виду, что понадобится много тестов для тестирования нюансов поиска — но это нужно тестировать не через UI. Там обязательно надо использовать модульные и интеграционные тесты, а вовсе не BDD и не Cucumber.
А про PageObject надо добавить, спаисбо.
Интерфейс (т.е. UI) поиска гугла, как известно, крайне простой. Для тестирования UI больше тестов не нужно.
Вот этого одного теста достаточно.
BDD вообще-то нужно для того, чтобы с заказчиком проговаривать бизнес-требования и записывать в виде тестов. В данном случае требований немного и они все в тесте уже отражены. Вы, видимо, имеете в виду, что понадобится много тестов для тестирования нюансов поиска — но это нужно тестировать не через UI. Там обязательно надо использовать модульные и интеграционные тесты, а вовсе не BDD и не Cucumber.
А про PageObject надо добавить, спаисбо.
Хм, я бы поспорил. На самом деле если вы тестируете гугл — вы ещё будете наверное несколько вещей проверять. Например что по ходу ввода вываливаются подсказки. Сколько блоков AdWords есть на странице. Что при поиске знаменитостей вываливается карточка с краткой информацией. Аналогично при поиске георафических единиц. Что до того как мы начали искать мы видим две кнопки для поиска. Что результаты поиска отличаются когда мы залогинены и когда нет (ладно, это спорно, согласен). Это всё нюансы интерфейса.
А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
Согласен, функциональности там действительно значительно больше, чем мне казалось. Наверное, я никогда не искал знаменитостей. :)
Но изначальное утверждение, что первый тест ужасен — категорически не могу принять. Я могу написать качественные тесты на все перечисленные функции безо всякого BDD.
> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
А кто же вам мешает любые другие тесты писать так, чтобы было понятно?
А кто вам мешает любой код делать самодокументирующимся?
Почему для этого непременно нужен какой-то там магический BDD? Без BDD никак, а возьми BDD — и оно само вдруг получится? Ага.
Но изначальное утверждение, что первый тест ужасен — категорически не могу принять. Я могу написать качественные тесты на все перечисленные функции безо всякого BDD.
> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
А кто же вам мешает любые другие тесты писать так, чтобы было понятно?
А кто вам мешает любой код делать самодокументирующимся?
Почему для этого непременно нужен какой-то там магический BDD? Без BDD никак, а возьми BDD — и оно само вдруг получится? Ага.
Он сделает написание самодокументирующегося кода проще, а код структурированнее. Более того, BDD-фреймворки дают возмоность простыми словами, насколько угодно длинно описать каждый сценарий, юезрстори и степ. В джаве, увы, у вас не может быть, например, пробелов в названии метода. И это автоматически значит что вам придётся эти названия методов расшифровывать.
Насчёт того, что вы можете написать качественные тесты — я, в общем-то, не сомневаюсь. Вопрос в том, сколько будет стоить поддержка этого дела. Так-то вообще все тесты чего угодно можно загнать в один метод и сказать, что так всё просто и понятно.
Но конечно же всё что я написал можно сделать и без BDD, просто сложнее. Можно Allure приделать, например, который даст методам нормальные дескрипшны, к TestNG который даёт зависимости методов друг от друга.
Насчёт того, что вы можете написать качественные тесты — я, в общем-то, не сомневаюсь. Вопрос в том, сколько будет стоить поддержка этого дела. Так-то вообще все тесты чего угодно можно загнать в один метод и сказать, что так всё просто и понятно.
Но конечно же всё что я написал можно сделать и без BDD, просто сложнее. Можно Allure приделать, например, который даст методам нормальные дескрипшны, к TestNG который даёт зависимости методов друг от друга.
Для меня ваш 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) (предположение как выглядел бы вменяемый интерфейс к калькулятору)? Вместо одной строчки!
Это Вам кажется, что сложнее, потому что Вы не пробовали. Попробуете писать на обычных тест-фреймворках — у вас код будет лаконичнее и тестов, и самого тестируемого кода.
Это дополнительный уровень инфраструктуры в вашем коде. Имхо, проще добавить 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) (предположение как выглядел бы вменяемый интерфейс к калькулятору)? Вместо одной строчки!
Это Вам кажется, что сложнее, потому что Вы не пробовали. Попробуете писать на обычных тест-фреймворках — у вас код будет лаконичнее и тестов, и самого тестируемого кода.
> На самом деле если вы тестируете гугл — вы ещё будете наверное несколько вещей проверять.
Только это будет уже другие тесты.
> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
Фигня это все. Этот недоанглийский подходит только для очень простых вещей, которые легко читаются и без него. Правильное использование PageObject'ов с легкостью заменяет весь этот модный BDD.
Только это будет уже другие тесты.
> А ещё BDD хорош тем, что нам самим из текстов понятно что имненно мы тестируем. Самодокументирующийся код и вот это вот всё.
Фигня это все. Этот недоанглийский подходит только для очень простых вещей, которые легко читаются и без него. Правильное использование PageObject'ов с легкостью заменяет весь этот модный BDD.
Если коротко, в Selenide каждый метод умеет немножко подождать, если надо. Люди называют это «умными ожиданиями».
Правильно я понимаю, что это должно полностью избавить от проблем со stale element reference exception? И каким образом реализовано это умное ожидание?
Да, это должно избавить от проблем со stale element exception в большинстве случаев. Совсем полностью невозможно даже теоретически. Всегда можно написать приложение и тест, который выкинет stale element, как ни старайся.
А реализовано «умное ожидание» очень просто:
while (прошло меньше 4 секунд) {
try {
element.doOperation();
}
catch (WebDriverException e) {
sleep(10);
}
}
Sign up to leave a comment.
Эффективные UI-тесты на Selenide