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. Поехали!