Поддержу в этом мега-трэде @asolntsev. Шаблон нужен, когда у вас одна и та же страница используется многократно.
Но если у вас одна и та же страница используется многократно, это значит, что вы в разных тестах делаете одно и то же. PageObject вам поможет избавиться от дублирования в коде, но не избавит вас от дублирования в выполнении тестов. От этого избавляет нормальная модульная архитектура приложения и более низкоуровневые тесты, ну и ли набившая всем уже оскомину “Пирамида”.
Сейчас работаю на проекте, где у нас 4000 юнит-тестов (некоторые из них слегка интеграционные), 100-200 интеграционных API тестов, пару сотен UI Unit Test’ов. Так вот необходимости в классических UI-тестах с Selenium’ом пока не возникло, так как бизнес-логика тестируется другими способами, быстрее чем это сделали бы через браузер. Вместо Selenium’a пока нам удобнее пройти руками, чтобы заодно протестировать вещи, которые автотесты не найдут. В общем, живём без Page Object’a.
Всё просто. Я не защищаю яростно PageObject. Я говорю, что если уж его использовать, то правильно его использовать как средство создание DSL. А все его обычно используют как помойку для локаторов.
Господь с вами, никаких антипаттернов я не продвигаю. Я как раз говорю, что сотрудничество с разработчиками означает (среди прочего), что разработчики будут делать читаемые и короткие локаторы. И тогда такой вариант: $("#firstName").val("john") будет ничем не хуже, чем такой: page.enterFirstName("john"). Если же локаторы нечитаемые и представляют из себя “магические строки”, то да, конечно, пэдж обжекты помогут скрыть эту проблему. Подчёркиваю: скрыть, но не решить!
Нет, конкретно это предложение говорит о том, что недостатки есть не у пэдж обжектов вообще, а конкретно у такого стиля пэдж обжектов, когда элементы объявляются как поля класса. Проблема, которую я имел в виду, вам наверняка хорошо известна: этот способ не поддерживает динамические локаторы, динамические элементы и всё такое. А этого добра становится всё больше.
Ну да, верно, для промоушина это звучит явно лучше. Спасибо. Надо будет ещё подредактировать.
Да, считаю, потом что в своих приложениях мы используем не “q”, а читаемый локатор типа “id=query”. И тогда действительно $("#query").setValue(query).pressEnter(); ничем не хуже.
Про fname отличный вброс, пять баллов! Если можно, я его буду цитировать в блогах и на конференциях.
На самом деле мы проповедуем понятие “чистый код” (clean code) и в коде, и в тестах. Если кто-то назовёт переменную “fname” или локатор “fname”, это будет одинаковой плохой говнокод. Конечно, мы назовём переменную “firstName”. Мой пример с “fname” был, конечно, неудачный.
Повторюсь: потому что мы сами придумываем локаторы. А те, кто сам не может, должен требовать этого от разработчиков. Для компании в целом будет гораздо эффективнее, если разработчики потратят немножко времени и напишут нормальные локаторы, чем если тестировщики будут городить конструкции, пэдж обжекты, фреймворки, микросервисы и парки серверов только лишь потому, что они не могут достучаться до разработчиков.
Это ограничение не PageObject'a или его вариаций. Это ограничение самого WebElement'a / PageFactory. Т.е. архитектурно эта связка не заточена для таких целей. Обычный technical debt, я бы сказал. Кому такой подход не нравился, или был недостаточен, уже давно изобрели свои кастомные обертки, поддерживающие динамические локаторы. Но концепция PageObject'а то от этого не поменялась.
Вариант 1. Вы и швец и жнец разработчик => вы можете писать тесты как угодно, ведь если что-нибудь “пойдет не так”, вы всегда сможете “подкрутить” приложение, что бы исправить ситуацию.
Вариант 2. Вы опытный автоматизатор => вы можете писать тесты как угодно, ведь если что-нибудь “пойдет не так”, вы всегда сможете предупредить эту ситуацию до точки “не возврата” – когда усилия, которые нужно будет затратить на рефакторинг, будут сопоставимы с усилиями на “переписать все с нуля”.
Вариант 3. Вы начинающий автоматизатор и каждый член команды перед каждым комитом ждет вашего апрува “Будет ли это ‘удобно’ тестировать?” => вы можете писать тесты как угодно, ведь если что-нибудь “пойдет не так”, вы всегда сможете спихнуть это на “коммитеров”.
Вариант юмористический. Вы начинающий автоматизатор и ваша команда - это нордические бородатые дядечки “перепиливающие” “довоенный” модуль с фортрана на плюсы, которым нету дела до ваших проблем, потому что у них “горят” сроки => вы можете писать flat тесты, ведь если что-нибудь “пойдет не так”, вы всегда сможете спихнуть это на начальство – объяснить ему, что у нас “неэффективный процесс разработки” и заставить всю команду на ежедневных стендап-митингах смотреть презентации тов. @asolntsev’a в профилактических целях.
Вариант реалистический. Вы начинающий автоматизатор и: не знакомы с анти-паттернами в программировании, не можете прогнозировать эволюцию своего кода, не знакомы с рефакторингом => пишите тесты используя общепринятые практики, что бы минимизировать возможные риски, ведь если что-нибудь “пойдет не так” – виноваты будете только вы.
Очень понравился ваш ответ, хоть я таки я раньше решил использовать эту практику и стараюсь внедрить site-prism, ваш ответ переубедил меня окончательно
testomat.io управление авто тестами