E2E-тесты: Playwright и Cypress
↑ 6.3 Качество кода и тестирование: продвинутый уровень · ← Предыдущая · → Следующая
Зачем это на собесе
E2E проверяет критические пути; спрашивают про flaky-тесты, изоляцию данных и выбор инструмента.
Playwright
import { test, expect } from '@playwright/test'
test('пользователь создаёт заказ', async ({ page }) => {
await page.goto('/orders')
await page.getByRole('button', { name: 'Новый заказ' }).click()
await page.getByLabel('Клиент').fill('ООО Ромашка')
await page.getByRole('button', { name: 'Сохранить' }).click()
await expect(page.getByText('Заказ создан')).toBeVisible()
})Особенности: несколько браузеров (Chromium, Firefox, WebKit), авто-ожидание элементов, trace viewer, параллельный запуск, storageState для входа один раз.
Playwright vs Cypress
| Playwright | Cypress | |
|---|---|---|
| Браузеры | Chromium, Firefox, WebKit | Chromium-семейство, Firefox |
| Вкладки и домены | поддерживает | ограничено |
| Параллельность | из коробки | платная в облаке или плагины |
| Отладка | trace viewer | time travel в runner |
| Язык | TS/JS, также Python, .NET, Java | JS/TS |
Против flaky-тестов
- полагаться на авто-ожидание, а не на
sleep; - локаторы по роли и
data-testid; - тестовые данные создавать через API, а не через UI;
- независимость тестов: каждый сам готовит и убирает данные;
- сеть: мокать сторонние сервисы через
page.route; - повторы (
retries: 2) только в CI, и анализ причин.
Что покрывать
Критические пути: вход, оформление, платёж, главные CRUD-сценарии. Не пытаться покрыть всё E2E.
Вопросы с ответами
Почему E2E-тесты нестабильны и как это лечить?
Гонки с асинхронностью, общие данные, реальная сеть. Лечится авто-ожиданием, изоляцией данных, моками внешних сервисов и разбором причин, а не слепыми retries.
Зачем нужен storageState?
Сохраняет сессию после логина, чтобы не логиниться в каждом тесте, ускоряя набор.