Learnly
Автоматизация тестирования веб-приложений с Playwright/Глава 1/Урок 2

Когда стоит использовать Playwright

Когда стоит использовать Playwright (и когда, нет)

E2E-тесты дороже, медленнее и чаще ломаются, чем unit-тесты. Поэтому правильный вопрос, не «как сделать Playwright», а какие сценарии стоят затрат на e2e, а какие лучше закрыть слоями ниже.

В этом уроке: тестовая пирамида и место Playwright в ней, конкретные кейсы, где Playwright выигрывает у альтернатив, антипаттерны.

Тестовая пирамида (актуальная версия 2026)

       /\
      /  \    e2e (Playwright)
     /----\   ── 5–15% всех тестов; критические user-сценарии
    /      \
   /--------\ component / integration (Vitest + Testing Library, Storybook test)
  /          \── 15–30%; компоненты с реальным DOM, без полного приложения
 /------------\
/______________\ unit (Vitest, Jest)
                ── 60–80%; чистая логика, утилиты, хуки, редьюсеры

Playwright, верхушка. Не тащите туда то, что закрывается ниже.

Когда Playwright, правильный выбор

1. Critical user journeys

Сценарии, провал которых = потеря денег / репутации:

  • Регистрация и авторизация.
  • Чекаут / оплата.
  • Создание основного объекта продукта (заказ, проект, документ).
  • Доставка финального действия (отправка email, создание PR, отправка transaction).

Эти flow затрагивают frontend + backend + БД + внешние сервисы. Только e2e даёт уверенность, что всё работает вместе.

2. Cross-browser проверка несовместимостей

Когда продукт деплоится для широкой аудитории:

  • WebKit (Safari iOS / macOS), частые проблемы с date inputs, flexbox, CSS gap, Service Workers.
  • Firefox, особое поведение с <dialog>, scroll snap, fetch streams.
  • Chromium, best-supported, но проблемы тоже бывают (Shadow DOM, Trusted Types).
// playwright.config.ts
projects: [
  { name: 'chromium', use: devices['Desktop Chrome'] },
  { name: 'firefox',  use: devices['Desktop Firefox'] },
  { name: 'webkit',   use: devices['Desktop Safari'] },
  { name: 'mobile-safari', use: devices['iPhone 14'] },
  { name: 'mobile-chrome', use: devices['Pixel 7'] },
]

Один npx playwright test, параллельно во всех проектах.

3. Регрессионные сценарии после критичных багов

Каждый раз, когда продакшн упал из-за edge-case (специфичный input, race condition, integration bug), добавляйте Playwright-тест на этот сценарий. Это превращает каждый incident в постоянную проверку.

4. Workflows с авторизацией / multi-step

  • OAuth-флоу с редиректами.
  • SSO (SAML / OIDC).
  • Multi-tenant: переключение организаций.
  • Импорт/экспорт файлов.

Playwright + storage_state (сохранённая авторизация) делает это тривиальным:

// auth.setup.ts, выполняется один раз
await page.goto('/login');
await page.fill('[name=email]', 'admin@test.com');
await page.fill('[name=password]', 'secret');
await page.click('button[type=submit]');
await page.context().storageState({ path: 'playwright/.auth/user.json' });

// в тесте, авторизованный сеанс уже готов
test.use({ storageState: 'playwright/.auth/user.json' });

5. Network-зависимая логика с моками

Перехватываем backend-ответы и проверяем UI-поведение в любых сценариях (5xx, slow network, partial data) без бэкенда:

await page.route('**/api/orders', route =>
  route.fulfill({ status: 500, body: 'Server error' })
);
await page.goto('/orders');
await expect(page.getByRole('alert')).toContainText('try again');

6. Visual regression на критичных экранах

await expect(page).toHaveScreenshot('checkout.png', { maxDiffPixels: 100 });

Для серьёзного visual-baseline-management, Percy / Chromatic / Argos / Lost Pixel поверх Playwright. Не пытайтесь хранить тысячи скриншотов в git.

7. Accessibility (a11y) regressions

import AxeBuilder from '@axe-core/playwright';
const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);

Автоматическая проверка контрастности, ARIA, keyboard navigation, focus order.

8. PDF / file download / upload flows

Реальные file inputs, реальные браузерные диалоги (которыми Playwright умеет управлять):

const downloadPromise = page.waitForEvent('download');
await page.click('text=Export PDF');
const download = await downloadPromise;
expect(download.suggestedFilename()).toMatch(/\.pdf$/);

9. AI-агенты, которые «работают» в браузере

Перспективная категория 2025–2026. Claude Computer Use, OpenAI Operator, Browser-use, Skyvern, Anthropic browser-use, все используют CDP / Playwright для browser automation. Если строите своего AI-агента поверх веба, Playwright самый удобный API.

Когда Playwright, НЕ ваш выбор

1. Чистая бизнес-логика

Утилиты, хелперы, валидация формы, расчёт скидки, форматтер чисел → Vitest / Jest. Один тест 50ms vs 5s в Playwright.

2. Изолированные React/Vue/Svelte-компоненты

Используйте Vitest + Testing Library или Playwright Component Testing (отдельная фича, не e2e). Поднимают только компонент в JSDOM/реальном браузере, без полного приложения.

// vitest + RTL пример
import { render, screen } from '@testing-library/react';
test('button shows label', () => {
  render(<Button>Click</Button>);
  expect(screen.getByRole('button')).toHaveTextContent('Click');
});

3. Тесты API / backend-routes

Для REST/GraphQL, supertest, vitest, axios + jest. Тесты в 50× быстрее e2e и не требуют браузер. Хотя Playwright тоже умеет делать request.fetch() напрямую, это удобно для smoke-проверок API без UI.

4. Native mobile apps

iOS / Android: Maestro, Appium, XCUITest, Espresso, Detox (для RN). Playwright, только для веба (включая мобильные браузеры).

5. Desktop приложения

Electron поддерживается частично (через _electron). Полноценное desktop-тестирование, WinAppDriver, Squish, Sikuli, robotjs.

6. Нагрузочное и performance-тестирование

  • Throughput, RPS, нагрузка → k6, Locust, JMeter, Artillery, Gatling.
  • Frontend-производительность (Web Vitals, Lighthouse) → Lighthouse CI или Lighthouse инсайды Playwright (page.evaluate Web Vitals API), но это micro-benchmarking, не нагрузка.

7. Безопасность / penetration

Burp Suite, OWASP ZAP, специальные инструменты. Playwright не для fuzz / SQL injection / XSS detection.

Решение: Playwright vs Cypress vs Selenium для нового проекта 2026

Критерий Лучший выбор
Multi-browser обязателен (включая WebKit/Safari) Playwright
Multi-tab, multi-domain, multi-origin сценарии Playwright
Команда фронта на TS, любит DX Любой подходит, Playwright чуть лучше по фичам
BDD (Cucumber/Gherkin) для PM/QA Любой через cucumber-плагин; Playwright + cucumber-js
Legacy QA-команда годами на Selenium Selenium, постепенная миграция
Только Chromium-only (внутренний tool) Cypress / Puppeteer / Playwright, любой
Visual regression first-class Playwright + Argos/Lost Pixel или Cypress + Percy
BrowserStack / SauceLabs кросс-девайсы Playwright или Selenium (оба интегрированы)
AI-агент в браузере Playwright (CDP-доступ)

Антипаттерны (то, что в e2e делать не нужно)

1. Тестировать каждый component в e2e. Это работа Vitest + Storybook test runner. E2e, для интеграции компонентов в реальный flow.

2. Тестировать стилизацию (margin/padding в пикселях). CSS unit-тесты бессмысленны; visual regression поверх делает это автоматически на критичных экранах.

3. Поддерживать 1000+ e2e тестов. При >300 e2e-тестов CI становится медленным, поддержка дорогой. Лучше 100 хороших, чем 1000 хрупких.

4. Использовать XPath / CSS-классы как локаторы. Хрупко; ломается на любом рефакторинге UI. Используйте getByRole, getByLabel, getByTestId.

5. Хардкодить await page.waitForTimeout(5000). Это маркер плохого теста. Всегда есть конкретное условие, которое можно дождаться (expect(...).toBeVisible(), waitForResponse, waitForLoadState).

6. Не использовать trace viewer. Сложные flaky-тесты вытащит trace. Включите trace: 'on-first-retry' в config.

Сколько e2e реально нужно

Эмпирическое правило для middle-size SaaS-продукта:

  • 5–15 critical journeys покрытых end-to-end (auth, main create flow, checkout, settings).
  • 30–80 happy-path тестов на ключевые экраны.
  • Component tests покрывают edge-cases UI.
  • Unit-тесты покрывают business logic.

Если у вас 500+ e2e-тестов, что-то не так в архитектуре пирамиды.

Главное

Playwright, мощный, но дорогой слой. Используйте его только для того, что нельзя проверить дешевле: критические user journeys, кросс-браузерная проверка, network-зависимые сценарии, accessibility. Всё, что можно проверить unit-тестом или component-тестом, закройте там, где быстрее и дешевле.

В следующем уроке, как Playwright устроен внутри: Browser / Context / Page модель, locator-стратегии, auto-wait и web-first assertions, network interception.

AI-тест
1 / 5

Какой вид тестирования Playwright лучше всего подходит для проверки критичных сценариев в реальных условиях?