Проверьте происхождение контекста
Запросы через page.request или browserContext.request используют хранилище cookies соответствующего браузерного контекста. Если пользователь уже вошёл в интерфейсе, API-запрос может получить его сессию. Ответ с установкой cookies также способен изменить состояние браузера. Это полезная возможность, когда тест намеренно проверяет один пользовательский сценарий через интерфейс и API. Но она становится скрытой зависимостью, если тест должен работать самостоятельно, а вход был выполнен другим шагом. Название переменной request само по себе не объясняет, какой именно объект используется.
Создайте явную границу состояния
Отдельный APIRequestContext, созданный через playwright.request.newContext(), имеет собственное хранилище cookies. Он не получает браузерную сессию автоматически. При необходимости авторизацию задают осознанно: через предусмотренный вход, заголовки или переданное состояние, в зависимости от устройства тестируемого приложения. Изоляция cookies не означает, что серверные данные тоже становятся отдельными. Два контекста могут обращаться к одной базе и одному учебному пользователю. Поэтому проверяйте обе стороны: клиентскую сессию и ресурсы, с которыми работает сценарий. Случайное разделение только одной из них не обеспечивает независимость тестов.
Сделайте ожидания частью проверки
Для учебного сервиса профиля можно определить два отдельных сценария: запрос без авторизации должен получить предусмотренный контрактом отказ, запрос с подготовленной сессией должен вернуть профиль нужного пользователя. Проверяют не только успешный статус, но и ожидаемую личность и значимые поля ответа. Точный код отказа задаётся контрактом API, а не догадкой тестировщика. Если сервер перенаправляет запрос на страницу входа, автоматическое следование перенаправлению может дать ответ, который требует отдельного анализа. Успешный HTTP-ответ с неожиданным содержимым не подтверждает правильную работу авторизации.
Управляйте подготовкой и завершением
Самостоятельно созданный контекст освобождают через dispose, когда он больше не нужен. Это завершает его клиентский жизненный цикл, но не удаляет созданные на сервере записи. Очистку учебных данных планируют отдельно, сохраняя идентификаторы только своих ресурсов. При разборе ошибки полезно фиксировать способ создания контекста, адрес тестовой среды, ожидаемую роль и существенные параметры запроса. Секреты и содержимое сессий в отчёт не включают. Сначала восстановите явные предусловия, затем оценивайте необходимость повторов: повторение не исправляет неясную модель состояния.
Попробуйте на практике
Спроектируйте две проверки авторизации для собственного учебного API без обращения к чужим сервисам.
- Опишите ожидаемый результат запроса профиля без сессии и с сессией учебного пользователя.
- Укажите, откуда берётся каждый APIRequestContext и должен ли он разделять cookies с браузером.
- Добавьте явную подготовку авторизации и проверку идентификатора пользователя в успешном ответе.
- Запланируйте отдельный запуск каждого сценария, чтобы обнаружить зависимость от предыдущего входа.
- Укажите завершение самостоятельно созданных контекстов и отдельную очистку собственных тестовых данных, если они создавались.
Как проверить результат. План корректен, если результат каждого теста объясняется его собственными предусловиями. В нём не требуется предварительно запускать другой тест ради случайно сохранённой сессии.
Частые вопросы
Общий контекст браузера и API всегда является ошибкой?
Нет. Он подходит для намеренного сквозного сценария одного пользователя. Ошибка возникает, когда общее состояние существует скрыто и противоречит цели проверки.
Вызов dispose удалит тестового пользователя на сервере?
Нет. Он освобождает ресурсы API-контекста. Удаление серверных данных является отдельным действием и должно быть явно предусмотрено для созданных тестом ресурсов.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.