BDR: Почему ваши тесты на Playwright флакают в CI и как перестать жечь на этом деньги? Lead-гайд (Часть 1)

26.03.2026 07:39:33 | Хабр

Хабы: Тестирование IT-систем, Тестирование веб-сервисов

Ваши тесты стабильно проходят локально, но в CI каждое утро — красный океан? Вы тратите часы на дебаг флаков, а стейджинг «ложится» в самый неподходящий момент? Знакомо? В этом гайде расскажу, как перестать жечь бюджет CI и превратить автотесты из источника боли в живую документацию, следуя методологии BDR (Behavior-Driven Living Requirements).

Почему это важно:
Если у вас уже 100+ тестов или вы только закладываете фундамент — неправильная архитектура будет стоить команде десятков часов дебага и простоя CI. Но есть проверенные практики, которые внедряются за пару часов и экономят деньги каждый день.

Вы узнаете:

Как использовать Dependency Projects вместо globalSetup, чтобы строить граф иммунитета и экономить 40 минут CI при падении окружения.

Почему авторизация через API — это база, а UI-логин должен быть только в одном тесте.

Как выбирать локаторы, чтобы не переписывать тесты после каждого апдейта фронтенда: getByTestId для действий, getByRole для проверок.

Почему isVisible() — зло, и как web-first assertions (с ретраями) убивают race conditions.

В чём ловушка гидратации и почему force: true — это маскировка проблемы, а не решение.

Как блокировать маркетинговый мусор (метрики, чаты), чтобы тесты не зависели от сторонних тормозов.

Как Trace Viewer превращает дебаг из гадания в машину времени: смотрим не просто скриншоты, а консоль, сеть и интерактивный DOM в момент падения.

Прагматичный подход к линтерам: что включать как error, а что — как warn, чтобы не перегнуть палку.

Для кого:
Для QA-инженеров, которые хотят поднять свои тесты на промышленный уровень. Для тимлидов, которые устали от горящего CI и хотят стандартизировать подход в команде. Для всех, кто использует Playwright и хочет спать спокойно.

Бонус:
Cheat sheet по web-first ассертам, шпаргалка частых флаков и готовые конфиги для playwright.config.ts и .eslintrc.js. А в конце — челлендж: примените 5 правил уже сегодня и оцените стабильность.

Часть 1 — фундамент стабильности. В следующей части разберём масштабирование: фикстуры, изоляцию данных, параллельный запуск и превращение тестов в живую документацию.

Подход и код — в открытом репозитории на GitHub. Поехали!

Подробнее

Читайте также