Повторне використання стану входу. Не видавати секрет.

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

Цей посібник дотримується документації автентифікації 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 або конфігурації входу. Менше повторюваних налаштувань корисно лише тоді, коли пакет усе ще захищає кордон автентифікації.