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

Ваши тесты стабильно проходят локально, но в 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. Поехали!