Вхід у Playwright: автоматизація автентифікації без нестабільних тестів
Take a Quick Look
Дізнайтеся, як автоматизувати вхід у Playwright за допомогою storageState, API-автентифікації, сесій на робітника та обробки MFA, щоб тестові набори були швидкими та стабільними.
🔥 Limited-Time Offer! Save extra 10% off on your first monthly plan with code: Anitdetect10
Sign upВхід у Playwright: автоматизація автентифікації без нестабільних тестів
Автоматизація входу в Playwright виглядає просто на перший погляд: відкрийте сторінку, заповніть email, введіть пароль, натисніть кнопку. Але коли тестовий набір перевищує кілька десятків тестів, той самий процес входу, який працював локально, починає давати збої в CI. Сесії закінчуються в середині виконання, паралельні робітники конкурують за один обліковий запис, і кожен тест платить податок у 5–15 секунд на вхід, перш ніж він взагалі почнеться.
Цей посібник пояснює, як правильно обробляти автентифікацію в Playwright. Ви дізнаєтеся, коли повторно використовувати збережену сесію, коли ізолювати облікові записи для кожного робітника, як автентифікуватися через API замість UI, а також як не дати MFA та OAuth потокам перетворити ваш конвеєр на вузьке місце.
Чому вхід у Playwright потребує стратегії
Playwright запускає кожен тест в ізольованому контексті браузера. Це означає, що файли cookie, localStorage та кеш окремі для кожного тесту за замовчуванням. Така ізоляція чудова для відтворюваності, але також означає, що автентифікація не переноситься автоматично. Без стратегії кожен тест входить з нуля.
При 20 тестах це дратує. При 200 тестах, що виконуються на восьми паралельних робітниках, це серйозна проблема. Кожен вхід через UI займає секунди. Помножте це на сотні тестів, і ви додасте від 10 до 25 хвилин чистого накладного часу на вхід до кожного запуску. Гірше, якщо всі робітники використовують один обліковий запис, одна зміна пароля або запит MFA зупинить весь набір.
Рішення полягає в тому, щоб розглядати автентифікацію як інфраструктуру, а не як шаблонний код у кожному тесті. Playwright надає вбудований механізм для цього: storageState.
Основний патерн: збережіть стан входу один раз, використовуйте всюди
API storageState у Playwright захоплює файли cookie та localStorage з автентифікованого контексту браузера та зберігає їх у файл JSON. Пізніші тести завантажують цей файл і починають вже автентифікованими.
Ось рекомендований робочий процес:
- Створіть каталог
playwright/.authі одразу додайте його до.gitignore. Файл стану містить сесійні файли cookie та токени, які можуть імітувати ваш тестовий обліковий запис. - Напишіть файл налаштування, який входить один раз і зберігає стан.
- Налаштуйте всі тестові проекти на завантаження цього збереженого стану.
Крок 1: Створіть файл налаштування
Створіть tests/auth.setup.ts:
import { test as setup, expect } from '@playwright/test';
import path from 'path';
const authFile = path.join(__dirname, '../playwright/.auth/user.json');
setup('authenticate', async ({ page }) => {
// Замініть на власні кроки входу.
await page.goto('https://github.com/login');
await page.getByLabel('Username or email address').fill('username');
await page.getByLabel('Password').fill('password');
await page.getByRole('button', { name: 'Sign in' }).click();
// Дочекайтеся фінальної URL-адреси, щоб переконатися, що файли cookie встановлені.
await page.waitForURL('https://github.com/');
// Збережіть автентифікований стан.
await page.context().storageState({ path: authFile });
});
Крок 2: Підключіть його до конфігурації
У playwright.config.ts оголосіть проект налаштування як залежність для всіх тестових проектів:
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{ name: 'setup', testMatch: /.*\.setup\.ts/ },
{
name: 'chromium',
use: {
...devices['Desktop Chrome'],
storageState: 'playwright/.auth/user.json',
},
dependencies: ['setup'],
},
{
name: 'firefox',
use: {
...devices['Desktop Firefox'],
storageState: 'playwright/.auth/user.json',
},
dependencies: ['setup'],
},
],
});
Крок 3: Напишіть тести, які починаються автентифікованими
import { test } from '@playwright/test';
test('dashboard shows user name', async ({ page }) => {
// page вже автентифікована.
await page.goto('https://github.com/');
});
Цей патерн добре працює, коли всі тести можуть виконуватися з тим самим обліковим записом, не заважаючи один одному. Якщо ваші тести змінюють стан на сервері, вам потрібен інший підхід.
Коли одного спільного входу недостатньо
Одна збережена сесія руйнується у двох поширених сценаріях:
- Тести змінюють стан на сервері. Один тест змінює налаштування, а інший його читає. Паралельне виконання з одним обліковим записом створює стани гонитви.
- Автентифікація залежить від браузера. Деякі застосунки прив'язують сесії до відбитків браузера або user-agent, тому стан, збережений у Chromium, не працюватиме у Firefox.
Для таких випадків Playwright рекомендує один обліковий запис на кожного паралельного робітника. Кожен робітник автентифікується один раз зі своїм обліковим записом, і всі тести в цьому робітнику використовують сесію робітника.
Фікстура автентифікації на робітника
Створіть playwright/fixtures.ts:
import { test as baseTest, expect } from '@playwright/test';
import fs from 'fs';
import path from 'path';
export * from '@playwright/test';
export const test = baseTest.extend<{}, { workerStorageState: string }>({
storageState: ({ workerStorageState }, use) => use(workerStorageState),
workerStorageState: [async ({ browser }, use) => {
const id = test.info().parallelIndex;
const fileName = path.resolve(test.info().project.outputDir, `.auth/${id}.json`);
if (fs.existsSync(fileName)) {
await use(fileName);
return;
}
// Автентифікуйтеся в чистому контексті.
const page = await browser.newPage({ storageState: undefined });
const account = await acquireAccount(id);
await page.goto('https://github.com/login');
await page.getByLabel('Username or email address').fill(account.username);
await page.getByLabel('Password').fill(account.password);
await page.getByRole('button', { name: 'Sign in' }).click();
await page.waitForURL('https://github.com/');
await page.context().storageState({ path: fileName });
await page.close();
await use(fileName);
}, { scope: 'worker' }],
});
Потім імпортуйте test з вашого файлу фікстур замість @playwright/test. Запис файлів автентифікації в testProject.outputDir означає, що Playwright автоматично очищає їх перед кожним запуском, тому застарілі сесії ніколи не потрапляють у наступне виконання.
Автентифікація через API замість UI
Для проектів налаштування вхід через UI рідко є найшвидшим шляхом. Якщо ваш застосунок підтримує автентифікацію через API, використовуйте фікстуру request у Playwright, щоб автентифікуватися без відкриття браузера. Це швидше та усуває нестабільність, пов'язану з взаємодією з формами, перенаправленнями та клієнтським рендерингом.
import { test as setup } from '@playwright/test';
const authFile = 'playwright/.auth/user.json';
setup('authenticate via API', async ({ request }) => {
await request.post('https://github.com/login', {
form: {
'user': 'user',
'password': 'password'
}
});
await request.storageState({ path: authFile });
});
Використовуйте API-автентифікацію для швидкості налаштування. Залиште тести входу через UI для спеціальних випадків, які перевіряють сам процес входу.
Підступність із sessionStorage
storageState за замовчуванням зберігає файли cookie та localStorage. Він не зберігає sessionStorage. Якщо ваш застосунок зберігає JWT-токени або ідентифікатори сесій у sessionStorage, стандартний патерн мовчки створює неавтентифіковані тести. Локально це працює, оскільки сесія браузера зберігається, а потім дає збій у CI.
Щоб перевірити, де ваш застосунок зберігає токени автентифікації, відкрийте DevTools після входу та перегляньте вкладку Application. Якщо токени зберігаються в IndexedDB, передайте indexedDB: true у storageState() (доступно з Playwright 1.51). Якщо вони в sessionStorage, вам знадобиться ручний обхідний шлях, який явно читає та відновлює значення.
Обробка MFA, OAuth та магічних посилань
Багатофакторна автентифікація тепер є стандартом для більшості організацій. Постачальники OAuth, системи SSO та магічні посилання на основі електронної пошти додають зовнішні залежності, які ваш тестовий набір не може повністю контролювати. Ось як тримати їх під контролем.
MFA та TOTP-коди
Для одноразових паролів на основі часу генеруйте коди у налаштуванні тесту за допомогою бібліотеки, наприклад otplib, із спільним секретом. Це дозволяє уникнути очікування доставки SMS або електронної пошти. Для кодів, що надсилаються електронною поштою, використовуйте тестовий сервіс електронної пошти з API, який можна опитувати з файлу налаштування.
import { authenticator } from 'otplib';
const code = authenticator.generate(process.env.TOTP_SECRET);
await page.getByLabel('Verification code').fill(code);
OAuth-потоки
Імітуйте OAuth на рівні функціональних тестів для швидкості, але збережіть принаймні один інтеграційний тест, який виконує реальний потік перенаправлення, обмін токенами та обробку зворотного виклику. Неправильно налаштовані URI перенаправлення та зламані реалізації PKCE виявляються лише під час тестування реального потоку.
Магічні посилання
Для потоків із магічними посиланнями перехоплюйте електронний лист за допомогою тестового API пошти, витягуйте URL-адресу підтвердження та переходьте безпосередньо за нею. Це дозволяє уникнути очікування, поки людина натисне посилання.
Поширені анти-патерни входу в Playwright
Уникайте цих помилок, які зустрічаються в реальних тестових наборах:
- Жорстко закодовані облікові дані в Git. Зберігайте облікові дані в змінних середовища або менеджері секретів. Витік файлів storageState — це інцидент безпеки, а не збій тесту.
- Глобально спільні токени автентифікації. Токен, збережений у глобальній змінній після першого тесту, створює прихований ланцюжок залежностей. Коли він закінчується в середині виконання, усі наступні тести падають.
- Очікування, залежні від часу. Використовуйте
page.waitForURL()абоexpect(locator).toBeVisible()замістьpage.waitForTimeout()після входу. Потоки автентифікації включають перенаправлення через кілька URL-адрес, а фіксовані затримки є найпоширенішим джерелом нестабільності. - Тестування лише щасливого шляху. Покрийте недійсні облікові дані, блокування облікових записів, прострочені MFA-коди та невдалі SSO-перевірки. Слабка логіка блокування — це проблема безпеки, з якою стикаються реальні користувачі.
- Залишені сесії між запусками. Записуйте файли автентифікації в
testProject.outputDir, щоб Playwright автоматично очищав їх. Явне прибирання серверних сесій підтримує узгодженість середовища.
Вхід у Playwright та багатооблікові робочі процеси
Патерни автентифікації Playwright чудово працюють в автоматизованому тестуванні, але ті самі принципи застосовуються, коли вам потрібно керувати кількома автентифікованими сесіями поза тестовим набором. Для команд, які керують операціями в соціальних мережах, керуванням магазинами електронної комерції або партнерським маркетингом через багато облікових записів, ізольовані профілі браузера з унікальними відбитками запобігають зв'язуванню облікових записів платформами та блокуванням.
Інструменти, як AdsPower, забезпечують цю ізоляцію на рівні браузера. Кожен профіль має власні файли cookie, localStorage та цифровий відбиток, тому вхід для одного облікового запису ніколи не перетікає в інший. AdsPower також пропонує Local API, який інтегрується з Selenium та Puppeteer, що означає, що ви можете застосовувати патерни автоматизації в стилі Playwright до реальних багатооблікових робочих процесів, не піддаючи сесії виявленню. Якщо ви порівнюєте антидетект-браузери для такої роботи, перегляньте AdsPower vs Octo Browser vs Hidemyacc для детального порівняння.
Для тестових наборів, які потребують перевірки узгодженості відбитків перед запуском автентифікованих тестів Playwright, поєднання профілів AdsPower з тестуванням відбитків BrowserScan допомагає виявити витоки IP та розбіжності профілів на ранній стадії.
Пов'язане читання
- Як використовувати AdsPower з Ticketmaster: налаштування та робочий процес - Дізнайтеся, як поєднати антидетект-браузер AdsPower з Ticketmaster для стабільних входів, доступу до черги та багатооблікових робочих процесів з квитками.
- Огляд Beautiful Soup 2026: чи варто його використовувати? - Поглиблений огляд Beautiful Soup, що охоплює переваги, обмеження, налаштування, ціни, ідеальні випадки використання та порівняння з Selenium і Scrapy у 2026 році.
- Як використовувати антидетект-браузер MuLogin: повний посібник з налаштування - Дізнайтеся, як налаштувати антидетект-браузер MuLogin, створювати ізольовані профілі, налаштовувати проксі та керувати кількома обліковими записами без блокувань у цьому практичному посібнику.
Джерела та додаткове читання
- Playwright - Керуйте файлами cookie, localStorage, sessionStorage та зберігайте/відновлюйте повний стан браузера для збереження автентифікації. Потребує можливості зберігання.
FAQ
Який найшвидший спосіб обробити вхід у Playwright?
Автентифікуйтеся один раз у проекті налаштування за допомогою фікстури request, збережіть стан за допомогою storageState() і завантажуйте цей стан у кожному тестовому проекті. Це усуває накладні витрати на вхід через UI для всіх тестів, окрім тих, що спеціально перевіряють процес входу.
Чи зберігає Playwright storageState sessionStorage?
Ні. storageState за замовчуванням зберігає файли cookie та localStorage. sessionStorage не зберігається. Якщо ваш застосунок зберігає токени автентифікації в sessionStorage, вам знадобиться ручний обхідний шлях. Підтримка IndexedDB доступна з indexedDB: true починаючи з Playwright 1.51.
Як запускати тести Playwright паралельно з автентифікацією?
Використовуйте один обліковий запис на кожного паралельного робітника. Створіть фікстуру з областю видимості worker, яка автентифікується один раз на робітника, використовуючи testInfo.parallelIndex для розрізнення облікових записів, а потім повторно використовуйте стан зберігання цього робітника для всіх тестів у робітнику.
Чи слід комітити файли стану автентифікації Playwright у Git?
Ніколи. Файли стану автентифікації містять сесійні файли cookie та токени, які можуть імітувати ваш тестовий обліковий запис. Додайте playwright/.auth до .gitignore і зберігайте облікові дані в змінних середовища або менеджері секретів.
Як тестувати вхід з MFA у Playwright?
Генеруйте TOTP-коди у налаштуванні за допомогою бібліотеки, наприклад otplib, із спільним секретом, або опитуйте тестове API електронної пошти для кодів, надісланих електронною поштою. Уникайте очікування реальної доставки SMS або електронної пошти в автоматизованих тестах.
Коли слід використовувати вхід через UI замість входу через API у Playwright?
Використовуйте вхід через UI лише у спеціальних тестах, які перевіряють сам процес входу: валідацію форми, обробку помилок, перенаправлення та запити MFA. Для всіх інших тестів автентифікація через API у проекті налаштування є швидшою та менш нестабільною.
Висновок
Автоматизація входу в Playwright — це вирішена проблема, якщо розглядати автентифікацію як інфраструктуру. Збережіть стан один раз за допомогою storageState, використовуйте його повторно в тестах та ізолюйте облікові записи для кожного робітника, коли тести змінюють стан на сервері. Автентифікуйтеся через API для швидкості, зарезервуйте вхід через UI для спеціальних тестів потоку та ніколи не комітьте файли автентифікації у свій репозиторій.
Різниця між набором, який виконується за 3 хвилини, і тим, що виконується за 25, рідко полягає в логіці тестів. Це те, чи платить кожен тест податок на вхід, чи починає вже автентифікованим. Створіть налаштування один раз — і весь ваш конвеєр стане швидшим.
Для додаткового читання офіційний посібник з автентифікації Playwright детально описує патерн проекту налаштування, а повний посібник Currents з тестування автентифікації досліджує OAuth, MFA та інтеграцію з CI у масштабі.