Паттерны автотестов

class CartPage:
    PAY = '[data-testid=pay]'
    def pay(self):
        self.page.click(self.PAY)
        return CheckoutPage(self.page)

# в тесте: CartPage(page).pay()
# и здесь же - проверки

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 11, остальные разбираются в тренажёре.

1. #design_patterns1 / 5
   Что держать в Page Object, а что — в самом тесте?

   A)В Page Object держат сами проверки (ассерты), а в тесте — локаторы элементов

   B)В Page Object хранят тестовые данные, а в тесте — методы взаимодействия со страницей

   C)В Page Object — локаторы и действия; в тесте — сценарий и проверки бизнес-смысла

   D)И локаторы, и сценарий, и проверки держат в одном классе теста ради простоты

   показать ответ и разбор

   +C)В Page Object — локаторы и действия; в тесте — сценарий и проверки бизнес-смысла

   // разбор: Разделение ответственности — суть паттерна. Page Object знает, КАК взаимодействовать со страницей: где элементы (локаторы) и как выполнить действие (кликнуть, ввести, отправить форму) — методы вроде fillLogin(), submit(). Тест знает, ЧТО проверяется: он выстраивает сценарий из этих действий (открыть логин → ввести → отправить) и делает проверки бизнес-смысла (после логина показана панель, баланс верен). Ассерты обычно живут в тесте, а не в Page Object, чтобы страница оставалась переиспользуемым «пультом», а проверки — гибкими под каждый сценарий. Так тест читаем, а детали UI изолированы.

2. #design_patterns2 / 5
   Почему локаторы не хардкодят прямо в каждом тесте?

   A)Потому что хардкод локатора замедляет поиск элемента на странице во время прогона

   B)Потому что тест с хардкодом локатора не запустится в headless-режиме браузера

   C)Потому что локаторы, вписанные в тест, видны в отчёте и раскрывают структуру страницы

   D)Дублированный по тестам селектор при перевёрстке приходится править везде

   показать ответ и разбор

   +D)Дублированный по тестам селектор при перевёрстке приходится править везде

   // разбор: Если селектор кнопки скопирован в двадцать тестов напрямую, то одно изменение вёрстки требует найти и поправить его во всех двадцати — вручную, с риском что-то пропустить и оставить часть набора красной. Это классическое нарушение DRY: одно знание («как найти эту кнопку») размазано по многим местам. Централизация локаторов в Page Object (или в отдельном реестре) делает правку одноточечной: изменили — и все тесты подхватили. Хардкод по тестам превращает поддержку в дорогую и хрупкую операцию, а по мере роста набора эта цена растёт лавинообразно, отчего команды и забрасывают такие наборы.

3. #design_patterns3 / 5
   Как принцип DRY проявляется в автотестах?

   A)Повторяющиеся шаги (логин, подготовка данных) выносят в хелперы и фикстуры

   B)DRY требует писать как можно больше тестов, чтобы покрыть каждый сценарий отдельно

   C)DRY означает запускать каждый тест дважды для подтверждения воспроизводимости результата

   D)DRY предписывает держать все шаги теста в одном длинном методе без вспомогательных функций

   показать ответ и разбор

   +A)Повторяющиеся шаги (логин, подготовка данных) выносят в хелперы и фикстуры

   // разбор: DRY (Don't Repeat Yourself) — «одно знание в одном месте». В тестах повторяется многое: логин перед сценарием, подготовка тестовых данных, типовые проверки, обёртки над действиями. Если копировать эти блоки из теста в тест, любое изменение (сменился флоу логина) придётся вносить во все копии — долго и с ошибками. Вместо этого общие шаги выносят в переиспользуемые хелперы, фикстуры (setup), базовые классы, Page Object. Тогда правка делается один раз и подхватывается всеми. DRY снижает объём кода и, главное, стоимость его поддержки — ключевого фактора живучести автонабора.

4. #design_patterns4 / 5
   Зачем отделять тестовые данные от логики теста?

   A)Чтобы тесты выполнялись быстрее, ведь данные из отдельного файла грузятся оперативнее

   B)Входы и ожидания выносят в параметры или фикстуры

   C)Чтобы скрыть тестовые данные от разработчиков, работающих с тем же репозиторием

   D)Чтобы каждый набор данных проверялся отдельным, независимо написанным тестом

   показать ответ и разбор

   +B)Входы и ожидания выносят в параметры или фикстуры

   // разбор: Когда конкретные значения (логины, суммы, ожидаемые результаты) вшиты в тело теста, каждый новый набор данных требует копии всего теста. Отделив данные (в параметры, таблицы, фикстуры, внешние файлы), один и тот же сценарий прогоняют на множестве входов — data-driven-подход: проверить логин на десятке валидных/невалидных пар, не дублируя код. Плюс: данные видно и легко менять/расширять, а логика сценария остаётся одна. Это и уменьшает дублирование, и повышает покрытие. Тестировщик добавляет строку данных, а не пишет новый тест.

5. #design_patterns5 / 5
   Каким должен быть хорошо написанный автотест по читаемости?

   A)Тест должен содержать как можно больше низкоуровневых команд драйвера для полноты контроля

   B)Тест лучше писать одним длинным методом без комментариев, чтобы он занимал меньше строк

   C)Читается как сценарий из бизнес-шагов (openLogin, submit, expect balance), а не из низкоуровневых кликов и селекторов

   D)Читаемость теста не важна: главное, чтобы он проходил, а понимать его будет автор

   показать ответ и разбор

   +C)Читается как сценарий из бизнес-шагов (openLogin, submit, expect balance), а не из низкоуровневых кликов и селекторов

   // разбор: Читаемый тест выражает намерение на языке предметной области: openLoginPage(), login(user), expectDashboardVisible() — по нему сразу понятно, что проверяется, даже без знания селекторов. Если же тело теста — россыпь driver.findElement(By.xpath(...)).click() и ручных ожиданий, смысл сценария тонет в технических деталях, тест труден для чтения и правки. Достигают читаемости выносом деталей в Page Object и хелперы, осмысленными именами методов и структурой «arrange-act-assert». Читаемый тест дешевле поддерживать и он сам служит документацией поведения.