Из-за изменения локатора десятки UI-тестов требуют правки, хотя пользовательские сценарии не изменились. Какой архитектурный механизм должен локализовать такие изменения?
Следует вынести локаторы и взаимодействие с элементами в отдельный слой Page Object или близкую ему компонентную модель. Тогда тесты описывают пользовательский сценарий через устойчивые операции, а изменение локатора затрагивает преимущественно один объект страницы.
Подход появился как ответ на типичную проблему UI-автоматизации: тесты напрямую содержали селекторы, команды взаимодействия и проверки. При изменении структуры интерфейса одинаковые технические детали приходилось исправлять во множестве сценариев, что увеличивало стоимость сопровождения и число ошибок.
Выделение объектов страниц стало способом отделить описание интерфейса от намерения теста. Тест хранит проверяемое поведение, а объект страницы — знания о том, где находятся элементы и как с ними взаимодействовать.
Если локаторы находятся непосредственно в тестах, один элемент может быть описан десятками разных способов. Переименование атрибута, изменение DOM-структуры или переход на другой компонент приводит к массовым правкам и повышает риск неполного обновления.
Простое вынесение селекторов без продуманного интерфейса проблему решает лишь частично. Тесты могут начать зависеть от внутренних деталей страницы, а чрезмерно крупный объект страницы станет трудным для понимания и будет скрывать реальные причины падений.
Создаётся объект страницы или переиспользуемого UI-компонента, который инкапсулирует локаторы и низкоуровневые действия: открытие страницы, заполнение формы, выбор значения, получение отображаемого состояния. Тест обращается к этим операциям на уровне пользовательского намерения, а не через конкретные селекторы.
Например, тест должен выражать действие «отправить заказ», а не последовательность поиска поля, ввода значения и нажатия кнопки. Если локатор кнопки изменился, корректируется реализация соответствующего объекта, но сам сценарий обычно остаётся прежним.
Полезно разделять ответственность:
Не следует превращать Page Object в универсальный слой, который знает весь бизнес-процесс приложения. Слишком много логики затрудняет переиспользование, скрывает шаги теста и может привести к неясным ошибкам. Также абстракция не отменяет необходимости выбирать устойчивые локаторы и корректно синхронизироваться с состоянием интерфейса.
Компромисс состоит в том, что дополнительный слой требует первоначального проектирования и поддержки. Он оправдан, когда интерфейс используется многими тестами или меняется независимо от сценариев; для единичного короткоживущего теста такая абстракция может быть избыточной.
В наборе тестов оформления заказа один и тот же локатор кнопки подтверждения находился в нескольких десятках сценариев. После переработки интерфейса часть тестов продолжила искать старый элемент, а часть использовала новые селекторы, из-за чего код стал неоднородным.
Рассматривались три варианта. Массовая замена локатора была бы быстрой, но сохранила бы дублирование. Использование только общих утилит поиска уменьшило бы повторение технического кода, однако не отделило бы сценарий от структуры страницы. Создание объекта страницы и отдельных объектов компонентов потребовало бы больше начальной работы, зато установило бы единый контракт взаимодействия.
Выбран был третий вариант: операции оформления заказа разместили в объекте страницы, а повторяемый блок адреса выделили в компонент. В результате изменение локатора стало локальным исправлением, а сценарии остались читаемыми; при этом проверки итогового статуса сохранили в тестах, чтобы бизнес-ожидания не скрывались внутри UI-слоя.
Он может предоставлять методы или свойства для получения состояния страницы, но обычно не должен скрывать все бизнес-проверки. Разделение позволяет использовать один объект в разных сценариях и явно видеть в тесте, какое условие проверяется. Допустимы локальные проверки технического состояния компонента, если они являются частью его корректного взаимодействия, например проверка доступности обязательного элемента перед действием.
Он уменьшает стоимость изменений локаторов, но не устраняет нестабильность из-за гонок, внешних зависимостей, случайных данных или неверной синхронизации. Если объект реализует действия через фиксированные задержки или хрупкие селекторы, проблемы просто будут сосредоточены в одном месте. Поэтому архитектурный слой нужно сочетать с ожиданием наблюдаемого состояния, изоляцией данных и диагностикой ошибок.
Компонент стоит выделять, когда часть интерфейса имеет собственное повторяемое поведение и встречается на нескольких страницах или в нескольких местах одной страницы. Это уменьшает дублирование без создания гигантского Page Object. Если же выделение не даёт повторного использования и только дробит простой сценарий на множество переходов, абстракция ухудшит читаемость и её следует отложить.