Паттерны аутентификации и навигации
Updated Jul 2026
Два наиболее распространённых антипаттерна в автоматизации браузерного тестирования появляются в первых тестах, которые пишет каждый QA-инженер: вход через UI перед каждым тестом и пошаговая навигация, дублирующая действия пользователя, вместо абстрагирования в переиспользуемые слои. Эти паттерны кажутся естественными — они отражают взаимодействие пользователей с приложением — но создают медленные, хрупкие, трудно поддерживаемые наборы тестов.
Ложь страницы логина
Антипаттерн: Каждый тест начинается с навигации на страницу логина, ввода имени пользователя и пароля и нажатия «Войти». Набор из 500 тестов тратит 40 минут только на вход в систему.
Паттерн: Аутентификация через API или сохранённое состояние браузера. Только сам тест логина должен тестировать страницу логина.
Аутентификация — это предусловие, а не тестируемая функциональность. Когда каждый тест проходит через процесс входа, вы:
- Тратите время (сетевые запросы, рендеринг UI, редиректы — умноженные на каждый тест)
- Создаёте хрупкость (любое изменение страницы логина ломает каждый тест в наборе)
- Маскируете реальные сбои (таймаут входа выглядит так же, как баг оформления заказа)
- Блокируете параллелизацию (общие пользовательские сессии конфликтуют между параллельными воркерами)
Пример паттерна: Подход storageState в Playwright — аутентификация один раз в проекте настройки, сохранение cookies и localStorage в файл и повторное использование этого состояния в каждом последующем тесте. Весь набор работает аутентифицированным, не касаясь страницы логина.
Page Objects как поведения, а не селекторы
Антипаттерн: Page objects — это тонкие обёртки вокруг селекторов:
loginPage.emailInput,loginPage.passwordInput,loginPage.submitButton. Тесты по-прежнему описывают низкоуровневые взаимодействия.
Паттерн: Page objects предоставляют поведения:
loginPage.loginAs(user),dashboardPage.createReport(params). Тесты описывают намерение, а не клики.
Трёхслойная архитектура, которая масштабируется:
| Слой | Ответственность | Пример |
|---|---|---|
| Слой тестов | Описывает что проверяется | expect(dashboard.reportCount).toBe(5) |
| Сервисный слой | Оркестрирует многостраничные рабочие процессы | app.createUserWithOrders(3) |
| Слой Page Object | Инкапсулирует взаимодействия с одной страницей | orderPage.fillShipping(address) |
Когда UI-элемент меняется, меняется только page object. Когда меняется рабочий процесс, меняется только сервисный слой. Тесты остаются стабильными, потому что описывают намерение, а не реализацию.
Ключевые выводы
- Аутентифицируйтесь через API или сохранённое состояние — только тест логина должен проходить через страницу логина
- Page objects должны предоставлять поведения (
loginAs,createReport), а не дескрипторы элементов (emailInput,submitButton) - Используйте трёхслойную архитектуру (тест / сервис / page object) для изоляции влияния изменений
- Каждая минута, потраченная на логин в большом наборе тестов — минута, потраченная впустую. Умножьте на сотни тестов, чтобы увидеть реальную стоимость