Параллельный запуск тестов в Playwright: workers и шардинг

Параллельный запуск — это выполнение нескольких тестов одновременно, а не по очереди, за счёт нескольких изолированных процессов (workers). Playwright запускает тесты параллельно по умолчанию: разные файлы тестов автоматически распределяются по воркерам, каждый воркер — это отдельный процесс с собственным браузерным контекстом, так что тесты не видят состояние друг друга и не мешают друг другу. Это резко сокращает время прогона: сьют, который последовательно шёл бы 20 минут, на 4 воркерах пройдёт примерно за 5-6 минут.

// playwright.config.js
export default {
workers: process.env.CI ? 2 : undefined,
fullyParallel: true,
};

По умолчанию Playwright определяет число воркеров сам — обычно берёт примерно половину доступных ядер процессора (это внутренняя эвристика раннера, а не строго гарантированный контракт: в Docker с ограничением по cgroup или на некоторых CI число ядер может определяться иначе). workers в конфиге переопределяет это значение — например, на CI часто ставят фиксированное небольшое число (2-4), потому что CI-раннеры обычно слабее локальной машины и лишние воркеры только замедлят прогон конкуренцией за ресурсы. fullyParallel: true включает параллельность не только между файлами, но и между тестами внутри одного файла — без этой настройки тесты одного файла по умолчанию выполняются последовательно в рамках своего воркера.

Каждый воркер — отдельный процесс Node.js с собственным экземпляром браузера. Это значит, что глобальные переменные, состояние модулей и side-эффекты одного теста не протекают в другой воркер — но именно поэтому тесты, полагающиеся на общее состояние (например, оба меняют одну и ту же запись в БД), могут начать конфликтовать при включении параллельности, если раньше проходили только благодаря последовательному запуску.
test.describe.configure({ mode: 'serial' });

test('шаг 1: создать заказ', async ({ page }) => { /* ... */ });
test('шаг 2: оплатить заказ', async ({ page }) => { /* ... */ });

test.describe.configure({ mode: 'serial' }) — способ явно сказать Playwright, что тесты внутри блока describe зависят друг от друга по порядку и должны идти последовательно в одном воркере, а не параллельно. Это осознанное исключение из параллельности для тестов, которые действительно образуют сценарий, а не для тестов, которые случайно конфликтуют из-за общих данных — во втором случае правильный путь — изолировать тестовые данные, а не отключать параллельность.

npx playwright test --shard=1/4
npx playwright test --shard=2/4
npx playwright test --shard=3/4
npx playwright test --shard=4/4
Воркеры распределяют тесты параллельно внутри одной машины. Шардинг (--shard) идёт на уровень выше — делит весь набор тестов на несколько частей и запускает каждую часть на отдельной машине или в отдельном job CI/CD. Четыре шарда на четырёх параллельных CI-раннерах сокращают время прогона примерно в четыре раза дополнительно к параллельности воркеров внутри каждого раннера. Разница практическая: workers — это про использование ресурсов одной машины, shard — про использование нескольких машин одновременно.

test.describe.configure({ mode: 'serial' });
// или для конкретного файла
export default { workers: 1 };

Для большинства UI-тестов параллельность безопасна и желательна. Но есть случаи, когда её стоит ограничить: тесты пишут в общую БД без очистки между собой, тесты проверяют глобальное состояние системы (например, счётчик, который меняют все тесты сразу), или окружение просто не выдерживает нагрузки от нескольких одновременных сессий браузера. Правильная стратегия — не выключать параллельность целиком, а изолировать конкретные конфликтующие тесты через serial-режим или отдельные тестовые данные для каждого теста (например, создавать нового пользователя в каждом тесте вместо одного общего).

Параллельность включена по умолчанию или её нужно настраивать? По умолчанию Playwright уже запускает разные файлы тестов параллельно в нескольких воркерах. Дополнительно включить параллельность тестов внутри одного файла можно через fullyParallel: true.
В чём разница между workers и shard? workers — количество параллельных процессов на одной машине. shard — деление всего набора тестов на части для запуска на разных машинах одновременно, обычно используется в CI/CD с несколькими параллельными job.
Как заставить тесты идти по порядку, если они зависят друг от друга? test.describe.configure({ mode: 'serial' }) для блока тестов, которые образуют последовательный сценарий и должны выполняться один за другим в одном воркере.
Почему тесты, которые проходили раньше, начали падать после включения параллельности? Чаще всего это конфликт по общим тестовым данным или общему состоянию (одна и та же запись в БД, один и тот же пользователь), которое одновременно меняют разные тесты. Решение — изолировать данные на каждый тест, а не отключать параллельность.
Параллельность и работа с фикстурами (изоляция состояния между тестами) — тесно связанные темы: подробнее про фикстуры и beforeEach — в статье «Фикстуры в Playwright».

Настроить изоляцию тестовых данных под параллельность — задача, где легче учиться на своём проекте, чем в теории. Бесплатный тренажёр Playwright Arena — для основ. А для разбора CI и архитектуры реального проекта с ментором — курс «Автотестирование JS/TS + Playwright» в Quality Academy.

-------

Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena