Повторно используйте состояние входа. Не разглашайте секрет.

Пакет выпуска регистрируется перед каждой небольшой проверкой. Большую часть времени мы проводим в ожидании одной и той же формы входа. Сохранение состояния аутентифицированного браузера может устранить это повторение, но сохраненный файл не является безобидными тестовыми данными. Он может содержать достаточно информации, чтобы выступать в качестве тестовой учетной записи.

Это руководство соответствует документации по аутентификации Playwright, чтобы сделать границу явной. Прилагаемый снимок экрана представляет собой экран локальной фальшивой учетной записи. Никакой реальный логин, токен или запись клиента не использовались. Вопрос в том, как безопасно подготовить повторно используемое состояние, а не в том, как обойти политику аутентификации приложения.

Решите, что пакету разрешено повторно использовать

Для проверки настроек профиля обычно требуется сеанс с аутентификацией. Нет необходимости повторно использовать форму входа. Сам тест входа в систему имеет другую задачу: проверить фактический поток аутентификации, поведение отклонения и соответствующие правила сеанса. Повторное использование состояния в первой группе не должно автоматически стирать вторую группу.

Запишите эти группы, прежде чем добавлять ярлык. Проект установки может выполнить одобренный вход в систему и сохранить состояние; зависимые тесты могут начинаться с этого состояния. Руководство по аутентификации показывает этот шаблон. Состояние должно принадлежать контролируемому тестовому идентификатору в утвержденной среде с только теми привилегиями, которые необходимы тесту.

// After your approved test-account login has completed:
await expect(page.getByRole('button', { name: 'Sign out' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

Видимая кнопка - это контракт готовности нашего иллюстративного приложения, а не универсальное доказательство того, что каждый метод аутентификации завершился. Вашему приложению может потребоваться другое стабильное состояние. Подождите, пока сеанс будет установлен, прежде чем сохранять его, иначе следующий тест может получить неполное состояние и привести к ошибочному сбою.

Файл принадлежит вне репозитория

Playwright предупреждает, что сохраненное состояние браузера может включать конфиденциальные файлы cookie и заголовки, которые можно использовать для выдачи себя за учетную запись. Его документация не рекомендует помещать эти файлы в частные или общедоступные репозитории. Частный репозиторий по-прежнему является каналом распространения, а не безопасным хранилищем учетных данных.

playwright/.auth/

Игнорирование каталога - это профилактика, а не исправление. Если файл состояния уже зафиксирован, его удаление из рабочего дерева не удаляет предыдущие версии. Прекратите распространение этого артефакта и следуйте процедуре раскрытия учетных данных вашей организации. Не помещайте файл реального состояния в руководство, не отправляйте вложение, пакет трассировки или снимок экрана, чтобы сделать объяснение более конкретным.

Просмотрите правила загрузки артефактов, а также правила управления версиями. После сбоя задание CI может загрузить всю рабочую область. Игнорируемый файл все равно может попасть в этот архив. Явно сохраняйте сохраненное состояние входа в пакеты отладки и резервные копии, которым оно не требуется. Используйте тестовые учетные записи и кратковременный доступ, если ваша среда их поддерживает.

Повторное использование - это не пожизненное обещание

Срок действия сохраненного состояния истекает. Руководство рекомендует удалить состояние с истекшим сроком действия и отмечает, что выходные каталоги проекта очищаются перед запуском. Выбирайте жизненный цикл, соответствующий политике сеанса, а не предполагайте, что вчерашний файл действителен вечно. Сбой установки должен останавливать зависимые проверки по уважительной причине, а не превращаться в десятки несвязанных сбоев страниц.

Механизмы хранения также имеют значение. В руководстве по аутентификации Playwright обсуждаются файлы cookie, локальное хранилище и другие механизмы, а также специальная обработка хранилища сеансов. Не думайте, что каждая реализация входа фиксируется простейшим вызовом StorageState. Проверьте, что использует ваше приложение, и убедитесь, что новый контекст может достичь намеченной аутентифицированной страницы.

В безопасном локальном эксперименте для демонстрации механизма используется фальшивое состояние. Это доказывает, что браузер может восстановить выбранное значение, а не то, что был проверен поставщик удостоверений, политика MFA или рабочий сеанс. Сохраните это различие в протоколе испытаний.

Предоставляем параллельным тестам достаточно независимое состояние

Повторное использование одной учетной записи может быть разумным для тестов только для чтения, которые не меняют состояние общего сервера. Становится рискованно, когда несколько тестов редактируют одни и те же настройки или записи. Разделение контекста браузера не делает учетную запись сервера отдельной. В нашем предыдущем руководстве по изоляции рассматривается это столкновение; здесь практическое правило состоит в том, чтобы согласовать настройку аутентификации с шаблоном мутации пакета.

Сохраните проверку готовности, область действия удостоверения, механизм хранения, правило истечения срока действия и исключения артефактов в небольшой заметке по настройке. Это примечание упрощает просмотр созданного теста. Рецензент может увидеть, почему вход в систему используется повторно, какие тесты входа все еще выполняются и где разрешено изменение состояния.

AnyTest описывает агентов, изучающих приложение и проводящих комплексные тесты для проверки человеком. Примените те же вопросы к любому предлагаемому подтвержденному путешествию. Это практика проверки, а не претензия по поводу хранилища учетных данных или конфигурации входа в систему AnyTest. Меньше повторной настройки полезно только в том случае, если пакет по-прежнему защищает границу аутентификации.