На 31 июля 2026 года строгий аудит проходит 199 из 358 созданных материалов. Остальные 159 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
На 31 июля 2026 года строгий аудит проходит 202 из 358 созданных материалов. Остальные 156 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
Registry, README, `articles.json`, очередь, Git и файлы других агентов не
менялись. Пакет не коммитился и не пушился.
## Историческая опора
Все источники являются официальными и были доступны к концу августа 2023:
- [Playwright v1.37.0](https://github.com/microsoft/playwright/releases/tag/v1.37.0) — опубликованный GitHub release от 10 августа 2023.
- [Auto-waiting, тег v1.37.0](https://raw.githubusercontent.com/microsoft/playwright/v1.37.0/docs/src/actionability.md) — для `click` перечислены attached, visible, stable, receives events и enabled; это actionability target, не бизнес-успех.
- [Retries, тег v1.37.0](https://raw.githubusercontent.com/microsoft/playwright/v1.37.0/docs/src/test-retries-js.md) — при failure worker с браузером отбрасывается, retry идёт в новом worker; `flaky` описывает failed → passed, а не причину различия.
- [Trace Viewer, тег v1.37.0](https://raw.githubusercontent.com/microsoft/playwright/v1.37.0/docs/src/trace-viewer.md) — записанный trace включает actions, snapshots, action log, source и network log; `on-first-retry` относится к первому retry.
<titleid="title">Классификация flaky e2e-теста без роста timeout</title>
<descid="desc">Последовательность из четырёх проверок: уникальность selector, semantic readiness, различие initial attempt и retry, evidence конкретной попытки. У каждого шага есть отдельное действие; timeout не является первым решением.</desc>
<textx="84"y="93"fill="#ffffff"font-family="Arial, sans-serif"font-size="34"font-weight="700">Flaky: классифицировать слой, не повышать timeout</text>
<textx="84"y="116"fill="#d9e2ec"font-family="Arial, sans-serif"font-size="17">Каждый ответ сужает следующую проверку; ни один не объявляет корневую причину.</text>
<textx="96"y="734"fill="#ffffff"font-family="Arial, sans-serif"font-size="23"font-weight="700">Только после этого: малый diff, owner, rollback. Timeout — верхняя граница, не readiness condition.</text>
<descid="desc">Пять шагов замкнутого цикла: зафиксировать initial и retry outcome, проверить selector, проверить readiness, связать evidence с попыткой, сделать маленький diff с rollback. При недостатке фактов цикл возвращается к карточке, а не повышает timeout.</desc>
<textx="84"y="92"fill="#ffffff"font-family="Arial, sans-serif"font-size="34"font-weight="700">Flaky triage: один факт → одна проверка → малый diff</text>
<textx="84"y="116"fill="#d9e2ec"font-family="Arial, sans-serif"font-size="17">Цикл не ищет «идеальный timeout»: он сохраняет объяснимый контракт и rollback.</text>
<textx="205"y="728"fill="#312e81"font-family="Arial, sans-serif"font-size="22"font-weight="700">Недостаточно фактов? Вернуться к карточке и собрать один недостающий сигнал.</text>
<titleid="title">Четыре контракта ожидания в e2e-тесте</title>
<descid="desc">Горизонтальная схема разделяет selector, actionability, readiness condition и retry. Под ними evidence привязан к попытке. Подписи показывают, что каждый слой не доказывает следующий.</desc>
<textx="84"y="91"fill="#ffffff"font-family="Arial, sans-serif"font-size="34"font-weight="700">Ожидание e2e: четыре разных контракта</text>
<textx="84"y="115"fill="#d9e2ec"font-family="Arial, sans-serif"font-size="17">Верхняя полоса — действие и результат. Нижняя — политика исполнения и evidence.</text>
<textx="102"y="538"fill="#5b21b6"font-family="Arial, sans-serif"font-size="26"font-weight="700">Evidence принадлежит попытке, а не всей истории</text>
<textx="102"y="574"fill="#334e68"font-family="Arial, sans-serif"font-size="20">Trace, snapshot и action log отвечают на один вопрос конкретного запуска.</text>
<textx="102"y="602"fill="#334e68"font-family="Arial, sans-serif"font-size="20">Если evidence записан on-first-retry, он не заменяет контекст initial failure.</text>
<textx="103"y="715"fill="#ffffff"font-family="Arial, sans-serif"font-size="23"font-weight="700">Правка меняет один слой: locator, readiness, test data или evidence policy. Не все сразу.</text>
note:'версионный срез, опубликованный до конца августа 2023. Он фиксирует выпуск, но не подтверждает версию, браузеры или настройку конкретного проекта.',
},
actionability:{
title:'Playwright v1.37.0: Auto-waiting, исходник официальной документации по тегу',
note:'для click описаны проверки attached, visible, stable, receives events и enabled. Эти проверки готовят действие с элементом, но не доказывают бизнес-результат после действия.',
},
retries:{
title:'Playwright v1.37.0: Retries, исходник официальной документации по тегу',
note:'описывает повторный запуск после сбоя, новый worker и статусы passed, flaky, failed. Статус flaky — классификация результата запусков, а не причина сбоя.',
},
trace:{
title:'Playwright v1.37.0: Trace Viewer, исходник официальной документации по тегу',
note:'описывает действия, snapshots, action log, source и network log; режим on-first-retry записывает trace при первом retry. Такой артефакт — evidence одного запуска, а не доказательство корневой причины.',
},
bestPractices:{
title:'Playwright v1.37.0: Best Practices, исходник официальной документации по тегу',
excerpt:'Почему retry не лечит e2e-падение: отделяем locator, условие готовности, повторный запуск и evidence, а timeout меняем только после проверки контракта.',
readingMinutes:12,
},[
p('Тест нажимает кнопку «Оплатить», получает ошибку на первой попытке и проходит на повторной. В отчёте остаётся статус flaky, а в pull request появляется короткое предложение: поднять timeout и идти дальше. Проблема в том, что этим действием смешиваются четыре разных объекта: selector для действия, условие готовности интерфейса, retry тест-раннера и evidence из конкретного запуска. Пока они смешаны, команда лечит паузу, а не контракт.'),
p('Цена такой правки не сводится к лишним секундам CI. Реальная ошибка может стать «шумом»: повторный запуск проходит, скрывает первый отказ и откладывает разбор. Обратная цена тоже заметна: бесконечный trace на каждый тест раздувает артефакты, но не отвечает, какой результат должен увидеть пользователь. Здесь нужен короткий порядок: сначала назвать факт после действия, затем выбрать наблюдение, только потом решать, нужен ли retry и какой evidence сохранять.'),
h2('Четыре объекта, которые нельзя называть одним ожиданием'),
p('Selector отвечает на вопрос «куда направить действие». Для Playwright 1.37.0 locator с role и name — это способ найти пользовательский элемент. Перед <code>click()</code> Playwright проверяет, что элемент attached, visible, stable, receives events и enabled. Эти проверки полезны: они не дают кликнуть в скрытый или перекрытый control. Но они не знают, завершилась ли оплата, сохранился ли профиль или пришёл ли пользовательский статус.'),
p('Readiness condition отвечает на другой вопрос: какой наблюдаемый продуктовый факт должен появиться после действия. Это может быть текст в <code>role=status</code>, появление записи в таблице или смена доступного пользователю состояния. Условие не должно быть «страница немного успокоилась» или «кнопка стала disabled», если бизнес-операция ещё не подтверждена. Retry запускает тест повторно после failure. Evidence — trace, snapshot, action log или другой артефакт отдельной попытки. Ни один из них не является синонимом selector или готовности.'),
table('Граница каждого слоя в e2e-сценарии',['Слой','На какой вопрос отвечает','Что может подтвердить','Чего не подтверждает','Первое действие'],[
['Selector','Как найти control?','locator разрешается ровно в один ожидаемый элемент','что операция завершилась','использовать role/name или явный test id'],
['Readiness condition','Какой факт увидел пользователь после действия?','конкретный status, текст, запись или состояние','что locator был уникален до click','сформулировать ожидаемый продуктовый результат'],
['Retry','Что сделал runner после failure?','первая попытка не прошла, следующая прошла или нет','почему попытки различаются','сохранить статус первой и повторной попытки'],
['Evidence','Что можно изучить в одном запуске?','действия, snapshots, log и network log, если они записаны','корневую причину без дополнительной проверки','связать артефакт с номером попытки'],
['Timeout','Каков верхний предел ожидания?','когда ожидание остановится ошибкой','какой факт надо дождаться','не менять, пока не назван readiness contract'],
]),
h2('Сначала формулируем результат после click'),
p('Практический контракт выглядит короче, чем кажется. После нажатия нужно назвать одно состояние, которое экран обязан показать. Например: «платёж подтверждён», а не «кнопка уже недоступна». Если интерфейс не имеет такого состояния, это не повод ждать произвольную паузу. Это повод вместе с владельцем экрана выбрать доступный сигнал: status region, итоговую строку, новый route или ответственный элемент в UI. Контракт должен быть проверяемым пользователем, а не внутренним CSS-классом без смысла вне реализации.'),
p('Ниже — проектный образец. <code>getByRole()</code> выбирает кнопку, а <code>toHaveText()</code> ждёт текст результата. Web-first assertion в Playwright умеет повторять проверку до timeout; это не означает, что любой текст подходит. Значение <code>confirmed</code> здесь специально условное: в своём продукте его заменяют на реальный, устойчивый и доступный пользователю результат. Фрагмент не доказывает, что страница, backend или browser уже проверены.'),
code(illustrativeTest),
p('Sleep или network idle без связи с результатом делают запуск длиннее, но не объясняют, что делать при ошибке экрана после успешного запроса. Actionability делает действие допустимым, readiness делает завершение сценария наблюдаемым. Тогда timeout — параметр договора, а не способ спрятать расхождение.'),
h2('Учебный fixture: только synthetic попытки в памяти'),
p('Пакет содержит исполнимую модель, но не e2e-запуск. Она создаёт две synthetic попытки: первая не достигает <code>payment-state=confirmed</code>, вторая достигает его после retry. Selector в обеих уникален, поэтому fixture отделяет readiness от selector и retry. Он не открывает URL, не читает тест, не запускает Playwright и не производит <code>trace.zip</code> или video.'),
code(fixtureCommand),
p('PASS проверяет шестнадцать утверждений: вход помечен как memory-only, браузер не запускается, первая и повторная попытки различаются ровно теми полями, которые заданы в модели, а увеличение timeout отклоняется учебным планом. Отдельная отрицательная ветка делает selector множественным и получает другую классификацию. Это важно: даже одинаковый финальный статус «flaky» не даёт права без проверки переписать locator, readiness condition и retry policy одной правкой.'),
figure('/assets/editorial/2023/e2e-stability-2023-flake-classification.svg','Схема классификации e2e-сбоя: сначала проверяется уникальность selector, затем отдельное semantic readiness condition, после этого сравниваются initial attempt и retry; trace-shaped evidence остаётся отдельным входом к проверке, а не причиной. Два выхода предлагают уточнить locator либо контракт готовности, а повышение timeout вынесено в отложенное решение.','Схема задаёт порядок разбора. Она не показывает настоящий trace, браузер, длительности, количество флаков или совместимость платформ. Каждый прямоугольник — вопрос к одному слою теста.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Первый запуск failed, retry passed, а отчёт пометил тест flaky. Сохраните номер попытки, исходный текст ошибки и ссылку на evidence, если ваш runner его записал. Не называйте это доказанной причиной.',
'<strong>Причина.</strong> Обычно в одном ожидании оказались selector, техническая готовность control и результат операции. Иногда к ним добавляют общий timeout, поэтому ошибка становится длиннее, но не яснее.',
'<strong>Проверка selector.</strong> Убедитесь, что locator на обеих попытках разрешается ровно в один пользовательский элемент. Если нет, это отдельная задача: сузить role/name, scope или test id; не менять пока бизнес-assert.',
'<strong>Проверка readiness.</strong> Выпишите факт, который обязан увидеть пользователь после действия. Сверьте, что assertion ждёт именно его, а не disabled button, исчезновение spinner или окончание произвольной паузы.',
'<strong>Проверка retry и evidence.</strong> Сопоставьте initial и retry как два запуска. Для Playwright 1.37.0 retry выполняется в новом worker; trace с <code>on-first-retry</code>, если он настроен, относится к первой повторной попытке. Он помогает задать вопрос, но не возвращает автоматически evidence первого отказа.',
'<strong>Действие.</strong> Внесите минимальную правку в один слой: locator, semantic assertion, изоляцию данных или явный проектный контракт. Не повышайте timeout, пока не можете назвать, что именно должно стать ready.',
'<strong>Rollback.</strong> До merge запишите прежний assertion и критерий возврата. Если новый сигнал оказался неверным, откатите только test diff и повторите разбор; не стирайте историю первой неудачной попытки комментарием «пофиксили flaky».',
]),
h2('Retry полезен как граница сбора evidence, а не как индульгенция'),
p('В Playwright retries выключены по умолчанию. При включении runner повторно запускает упавший тест; документация v1.37.0 называет flaky тот случай, когда первая попытка не прошла, а повторная прошла. Это удобный сигнал для очереди разбора, но не диагноз. Повтор может дать другой worker и чистое состояние, а значит скрыть утечку тестовых данных, зависимость от порядка или неявную готовность экрана. Он не доказывает, что первая ошибка была случайной, внешний сервис был медленным или selector корректен.'),
p('Конфигурация <code>trace: on-first-retry</code> привязывает артефакт к первому повтору, а не ко всей истории. Это evidence retry, не объяснение initial failure. Если нужен контекст первого отказа, проекту требуется отдельный способ его сохранить с учётом чувствительности данных и цены артефактов.'),
code(illustrativeConfig),
h2('Ограничения и следующий проверяемый шаг'),
p('Заметка не измеряет flake rate, не сравнивает браузеры, не обещает устойчивость любого <code>getByRole()</code> и не предлагает общий timeout. Trace фиксирует один запуск, а причина может лежать в приложении, сети, окружении или данных. Рамка ограничена Playwright v1.37.0 от 10 августа 2023; другую версию проверяют по её документации.'),
p('Следующий шаг — взять один тест со статусом flaky и заполнить короткую карточку из пяти строк: selector, readiness condition, initial outcome, retry outcome и доступный evidence. Затем выбрать один слой для изменения и указать rollback. Если карточку нельзя заполнить без догадок, не увеличивайте timeout. Сначала добавьте недостающий наблюдаемый результат или изоляцию данных. Так retry перестаёт превращать ошибку в шум и становится точкой, где начинается инженерный разбор.'),
excerpt:'Модель устойчивого e2e-теста: auto-wait готовит действие с элементом, readiness доказывает результат, retry классифицирует попытки, а trace остаётся evidence одного запуска.',
readingMinutes:13,
},[
p('У e2e-теста часто один большой timeout и один текст ошибки, хотя внутри живут четыре независимых контракта. Locator должен найти ровно тот control, auto-wait должен сделать действие допустимым, продуктовый assertion должен дождаться результата, а retry должен сохранить факт повторного запуска. Когда все четыре слоя названы словом «ожидание», падение становится непонятным: инженер видит TimeoutError, но не знает, кнопка не нашлась, была перекрыта, результат не наступил или retry изменил исходные условия.'),
p('После первой удобной правки команда повышает timeout, затем добавляет retry. Часть ошибок превращается в длинные flaky, CI медленнее, а trace не связан с гипотезой. Вместо этого один тест раскладывают на четыре контракта: у каждого свой вопрос, evidence, владелец изменения и rollback.'),
h2('Контракт действия не равен контракту результата'),
p('В Playwright 1.37.0 auto-wait перед <code>click()</code> проверяет набор actionability conditions. Для click это attached, visible, stable, receives events и enabled. Этот механизм решает узкую задачу: не отправить действие в элемент, который исчез, невидим, движется, перекрыт или disabled. Он не может узнать смысл вашей операции. Кнопка может быть полностью ready для click, но сервер вернёт отказ, клиент покажет validation error или асинхронное подтверждение не появится.'),
p('Поэтому после действия нужен второй контракт — readiness. Он принадлежит сценарию, а не библиотеке. Для оплаты это может быть подтверждённый статус; для сохранения профиля — видимое сообщение и обновлённое значение; для импорта — запись с терминальным состоянием. Условие должно быть достаточно узким, чтобы отделить success от промежуточного состояния, и достаточно пользовательским, чтобы пережить смену внутренней разметки. Если product UI не предоставляет такого сигнала, тест обнаруживает не только техническую проблему, но и недостающую наблюдаемость интерфейса.'),
table('Четыре контракта и их владельцы',['Контракт','Владелец смысла','Пример проверки','Негативный сигнал','Недопустимая подмена'],[
['Selector','автор теста и контракт доступной разметки','role/button с name или test id в нужном scope','0 или несколько совпадений','считать уникальный selector подтверждением операции'],
['Actionability','библиотека и состояние DOM перед действием','visible, stable, receives events, enabled для click','элемент не готов принять действие','ждать бизнес-успех только потому, что click допустим'],
['Readiness','продуктовый сценарий и UI-контракт','status, итоговая строка, terminal state','после действия нужный факт не наблюдается','проверять disabled/spinner вместо результата'],
['Retry','test runner и политика CI','номер попытки, outcome, новый worker','failed → passed или failed → failed','объявлять retry объяснением причины'],
['Trace evidence','артефакт конкретной попытки','actions, snapshots, log, source, network log при записи','evidence отсутствует или относится к другому запуску','выдавать артефакт за root-cause analysis'],
]),
h2('Auto-wait полезен, но у него есть предел'),
p('Auto-wait заменяет ручной sleep ожиданием технической допустимости target. Это снижает зависимость от отрисовки, но не делает интерфейс «готовым»: готов только target для одного действия. Синхронизация с сервером и итоговый статус лежат за границей actionability.'),
p('Уникальный locator с role/name находит пользовательский объект, но не является селектором сетевого ответа и не подтверждает update store. Assertion должен отвечать на вопрос «что увидит человек?», а не цепляться за внутренний CSS, который сломается при рефакторинге.'),
code(illustrativeTest),
p('Фрагмент не запускается вместе с fixture и не даёт готовый селектор для чужого приложения. Его задача — показать роль строк: <code>getByRole()</code> указывает действие, <code>toHaveText()</code> описывает постусловие. В более сложном сценарии readiness может состоять из нескольких согласованных фактов, но это не повод прятать их под <code>waitForTimeout()</code>. Лучше назвать один терминальный state, а дополнительные поля проверять отдельными assertions с понятным сообщением об ошибке.'),
h2('Retry меняет исполнение, но не причинность'),
p('Документация Playwright 1.37.0 описывает retry через worker process: после failure runner отбрасывает worker с браузером, а при включённом retry новый worker начинает с повторной попытки упавшего теста. Это важная техническая деталь для разбора. Повтор получает изолированный контекст исполнения и может не унаследовать причину, которая была в первой попытке. Значит, переход failed → passed — наблюдение о двух запусках, а не доказательство случайности, исправления или совместимости браузера.'),
p('Flaky — повод открыть карточку: фиксированные входы, expected readiness, selector, initial outcome и evidence retry. Общая запись или порядок набора могут исчезнуть в чистом retry context. Тогда правят данные или изоляцию, а не selector и timeout.'),
figure('/assets/editorial/2023/e2e-stability-2023-wait-contract.svg','Схема из четырёх слоёв: locator указывает на кнопку, actionability разрешает click, readiness проверяет пользовательский факт после click, retry повторно запускает тест, а trace-shaped evidence прикрепляется к конкретному номеру попытки. Между слоями отмечено, что один не доказывает другой.','Диаграмма объясняет контракт ожидания, а не показывает запуск браузера. В ней нет реальных URL, trace, video, длительностей или данных тестового окружения.'),
h2('Trace — evidence с известной областью действия'),
p('Trace Viewer версии 1.37.0 умеет показывать список действий, snapshots, action log, source и network log для записанного trace. Это хороший материал для вопроса «что происходило в этой попытке?». Например, можно заметить, что assertion начался до появления ожидаемого state, или что click пришёлся в другой control. Но нельзя перескочить от одного кадра к слову «причина». Trace не знает ожиданий бизнеса, а сетевой лог не доказывает, что серверная операция эквивалентна пользовательскому успеху без контракта UI.'),
p('Режим <code>on-first-retry</code> записывает trace при первом retry, поэтому evidence относится к повторной попытке. Он не восстановит initial failure. План диагностики сначала называет вопрос к artefact: selector, порядок action, видимый state или событие одного запуска.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Тест заканчивается timeout либо статусом flaky. Сначала запишите фазу: поиск locator, click, assertion результата или повторный запуск. Одно слово «упал» слишком мало для изменения.',
'<strong>Причина.</strong> Определите, какой контракт нарушен: cardinality selector, actionability control, readiness condition, изоляция данных или политика retry. Не выводите причину из длительности, если нет отдельного измерения.',
'<strong>Проверка selector и actionability.</strong> Сверьте user-facing locator и cardinality. Перекрытый или disabled элемент — ещё не проверка результата операции.',
'<strong>Проверка readiness.</strong> Запишите terminal state и наблюдаемый элемент. Замените assertion побочного индикатора на web-first assertion пользовательского факта.',
'<strong>Проверка retry.</strong> Сопоставьте initial и retry как разные worker contexts. Выясните, какие данные, настройки или cleanup не были частью контракта первой попытки.',
'<strong>Проверка evidence.</strong> Если проект записал trace, проверьте, к какой попытке он относится и какой вопрос может сузить. Не заявляйте, что просмотрели trace, пока артефакт не предоставлен.',
'<strong>Действие и rollback.</strong> Сделайте один малый diff и сохраните прежний assert либо config diff. Если contract не подтверждается, верните его и соберите evidence, а не поднимайте timeout.',
]),
h2('Учебная модель удерживает границы видимыми'),
p('Исполнимая часть sidecar не использует Playwright API. Она создаёт в памяти два marked synthetic outcome: initial failure с достигнутым selector и недостигнутым readiness, затем passed на first retry. Обе попытки обязаны нести одну и ту же synthetic retry-policy: иначе их нельзя сравнивать как один учебный сценарий. Функция возвращает классификацию <code>retry-masked-missing-readiness-contract-in-synthetic-input</code>. Длинное имя намеренно: оно не говорит «это настоящий flake», а сообщает, какую форму увидела модель. Вторая ветка делает selector множественным и получает отдельный результат; этим fixture не позволяет склеить два вида проблемы.'),
code(fixtureCommand),
p('Учебный plan принимает только readiness condition, совпадающий с condition из evidence; он не может подменить <code>payment-state=confirmed</code> произвольным удобным признаком. Timeout и selector change без evidence отклоняются. Это ограничение модели, не правило для всех проектов. Rollback возвращает неприменённый synthetic plan и сообщает, что test code и runner config не менялись.'),
h2('Ограничения модели и следующий шаг'),
p('Модель не запускает browser, не получает trace/video, не читает исходник, не знает CI, не измеряет duration и не выбирает domain condition. Она не оценивает реальную стабильность. Рамка — Playwright v1.37.0 от 10 августа 2023; другую версию сверяют отдельно.'),
p('Следующий шаг — написать для одного flaky теста компактный контракт из четырёх строк: user-facing locator, expected readiness, retry policy и evidence policy. Добавьте owner UI-сигнала и способ rollback тестовой правки. Если не удаётся сформулировать readiness без CSS или sleep, остановитесь и обсудите с владельцем экрана, какое состояние должен видеть пользователь. Этот разговор обычно дешевле, чем ещё один круг timeout и более полезен, чем случайный зелёный retry.'),
excerpt:'Разбор flaky без магии: фиксируем две попытки, классифицируем selector и readiness отдельно, используем trace как evidence и готовим обратимую правку.',
readingMinutes:13,
},[
p('В очереди CI появляется e2e-тест: initial attempt failed, first retry passed. До релиза час, и самое быстрое предложение — увеличить timeout или retries. Проблема в том, что policy меняется раньше минимальных фактов: selector, ожидаемый UI-result, событие первой попытки и evidence конкретного запуска.'),
p('Цена поспешного «исправления flaky» двойная. Если первая ошибка отражает неверный readiness contract, retry превращает её в нерегулярный шум и оставляет продуктовую границу непроверенной. Если причина в изоляции данных или внешней зависимости, общий timeout увеличивает время обратной связи для всех тестов. Полезный разбор ограничивает утверждения: статус flaky — это результат повторного запуска, trace — evidence попытки, а решение должно быть точечным и иметь rollback. До этих шагов слово «стабилизировали» использовать рано.'),
h2('Карточка разбора: пять фактов до изменения конфигурации'),
p('Начинаем не с видео и не с серии повторов. В карточке достаточно имени теста, initial/retry outcome, selector, readiness и ссылки или отсутствия evidence. Если trace сохранён только на retry, так и пишут: «attempt 1». Карточка удерживает разговор на фактах и не даёт перескочить от красного статуса к глобальной настройке.'),
p('Для selector важны форма и область: <code>getByRole('button', { name: 'Оплатить' })</code> внутри нужного диалога или контейнера — другой контракт, чем CSS-цепочка по классам. Для readiness важен терминальный факт: текст <code>confirmed</code> в status, новая строка с итогом или явный route. Для retry важен номер попытки и policy, а не эмоция «на второй раз повезло». Для evidence важно происхождение: trace, screenshot или log могут сузить вопрос, но должны быть привязаны к одному запуску и не обещать root cause.'),
table('Классификация без повышения timeout',['Наблюдаемая форма','Что уже известно','Чего ещё нет','Минимальная проверка','Безопасное действие'],[
['0 или несколько locator matches','нарушен selector contract','причина изменения DOM и корректный target','сузить scope, role/name или test id','исправить locator; readiness и retry не менять вслепую'],
['click не проходит actionability','control не готов для действия','успех операции после click','проверить overlay, disabled, animation или неправильный state','исправить предусловие экрана либо сценарий'],
['click проходит, readiness не достигнут','действие допустимо, ожидаемый факт не наблюдается','почему UI не получил нужное состояние','сверить semantic assertion и входные данные','уточнить UI-contract или изоляцию данных'],
['failed → passed на retry','две попытки имеют разные outcome','корневую причину и воспроизводимость','сравнить данные, worker boundary и evidence по попыткам','создать triage, не увеличивать timeout автоматически'],
['trace есть только на retry','есть контекст повторной попытки','контекст initial failure','подписать attempt и вопрос к артефакту','собрать отдельный evidence path, если он нужен'],
]),
h2('Политика retry должна сохранять сигнал'),
p('В Playwright v1.37.0 retries конфигурируются отдельно, а failed test запускается заново в новом worker. Поэтому retry — не «ещё немного подождать в той же странице». Он создаёт новую попытку с новой границей исполнения. Это удобно для независимых тестов и одновременно важно для диагностики: порядок, cookies, storage, server-side cleanup и данные могут вести себя иначе. Если тест зависит от предыдущего случая, повторный запуск иногда скрывает связь, потому что даёт более чистый контекст.'),
p('Flaky — маршрут в triage, не разрешение на merge. Временное исключение требует owner, срока, evidence policy и критерия снятия. Универсального числа retries нет: оно зависит от цены очереди, релиза и способности разобрать сигнал. Лучше оставить значение неизвестным, чем назвать его «стандартом». '),
code(illustrativeConfig),
h2('Trace помогает ставить вопрос, а не закрывать его'),
p('По документации Playwright 1.37.0 Trace Viewer показывает последовательность действий, snapshots, action log, source и network log для записанного trace. Режим <code>on-first-retry</code> связывает запись с первой повторной попыткой. Это полезно, если картинка или log помогают отличить «не тот control» от «после click не появилось нужное состояние». Но такой артефакт не подтверждает фактическое выполнение в другой попытке и не знает, какой бизнес-результат ожидался, пока тест не записал его assertion.'),
p('Пока у команды нет файла или ссылки, в карточке стоит <code>evidence: absent</code>. У артефакта сначала сверяют attempt, проект и тест, затем выбирают один вопрос: locator перед click или UI-state перед assertion. Запрос «найди причину по trace» слишком широк и поощряет первую красивую гипотезу.'),
figure('/assets/editorial/2023/e2e-stability-2023-triage-loop.svg','Цикл triage flaky e2e-теста: карточка фиксирует initial и retry outcome, затем отдельно проверяются selector и readiness; evidence привязывается к номеру попытки, после чего выбирается маленькая правка с owner и rollback. Если доказательств недостаточно, цикл возвращается к сбору одного недостающего факта, а не к увеличению timeout.','Схема показывает процедуру принятия решения. Это не trace, не отчёт CI и не измерение flake rate; в ней нет реальных тестов, браузеров, запросов или длительностей.'),
h2('Учебный fixture проверяет форму решения, а не качество теста'),
p('Чтобы не превратить текст в лозунг, sidecar содержит детерминированный fixture. Он создаёт два marked synthetic event/outcome объекта в памяти. У initial attempt selector уникален, но readiness <code>payment-state=confirmed</code> не достигнут; у retry тот же selector и readiness достигнут. Классификатор возвращает только форму <code>retry-masked-missing-readiness-contract-in-synthetic-input</code>. Он прямо маркирует, что не оценивал real flake, duration и browser compatibility.'),
code(fixtureCommand),
p('Fixture также моделирует множественный selector, расходящуюся retry-policy и evidence, где <code>actualTrace</code> перестало быть <code>not-produced</code>. Так реальный artefact нельзя подложить в учебный пример, а две попытки с разной policy нельзя выдать за сравнимый сценарий. Plan принимает только readiness change с owner, rollback, next check и condition, совпадающим с evidence; timeout или selector без evidence отклоняются. PASS проверяет процедуру, не стабильность настоящего теста.'),
h2('Маршрут: симптом → причина → проверка → действие'),
ol([
'<strong>Симптом.</strong> Зафиксируйте failed/pass как два outcome с номерами попыток. Не склеивайте их в фразу «иногда падает» и не удаляйте исходный error из обсуждения.',
'<strong>Причина.</strong> Сформулируйте конкурирующие классы: selector, actionability, readiness, test-data isolation или внешняя зависимость. Retry сам по себе не выбирает один из них.',
'<strong>Проверка selector.</strong> Проверьте cardinality и user-facing смысл locator. Нулевой или множественный match закрывает этот шаг отдельной правкой; не ждите ready state у неопределённой цели.',
'<strong>Проверка readiness.</strong> Сравните assertion с пользовательским результатом. Spinner, network idle или disabled state замените на semantic result, согласованный с владельцем UI.',
'<strong>Проверка evidence.</strong> Привяжите trace, log или screenshot к attempt. Для <code>on-first-retry</code> в v1.37.0 evidence относится к retry, поэтому initial failure может требовать отдельного способа сохранения контекста.',
'<strong>Действие.</strong> Выберите малый diff: locator, semantic assertion, изоляция данных или policy артефактов. Timeout меняют после названного события и доказанной верхней границы.',
'<strong>Rollback и следующий шаг.</strong> До merge зафиксируйте прежнее условие, owner и критерий возврата. После следующего запуска смотрите не на один зелёный retry, а на то, что новый contract проверяет нужный пользовательский факт.',
]),
h2('Маленький diff и явный rollback лучше широкой настройки'),
p('Если причина указывает на readiness, хороший diff меняет assertion и ничего больше: он ждёт терминальный UI-state, а retry/timeouts остаются прежними. Если причина указывает на selector, diff ограничивается locator и тестом его scope. Если нарушена изоляция, изменение может быть в setup/cleanup или фикстуре данных. Эти варианты имеют разный owner и разную цену. Общий timeout объединяет их в один параметр и поэтому редко даёт объяснимый rollback.'),
p('Rollback должен быть конкретным. Для assertion — вернуть предыдущую строку теста и снова собрать evidence; для selector — восстановить прошлый locator, если новый контракт не подтвердился; для данных — отменить созданную запись через тот же интерфейс подготовки. Для policy retry — вернуть прошлое значение отдельным config diff и указать, какие тесты это затронет. Нельзя считать rollback успешным, пока команда не понимает, какой слой откатывает. Учебная функция <code>rollbackSyntheticReadinessPlan()</code> специально ничего не применяет и возвращает это явным полем.'),
h2('Ограничения и следующий проверяемый шаг'),
p('Материал не содержит реального trace, video, браузерного запуска, CI-лога, оценки flake rate, duration или данных пользователя. Он не утверждает совместимость Playwright v1.37.0 с вашим окружением; version pin не заменяет проверку пакета и project config. Правило переносят только после review данных и рисков контура.'),
p('Следующий шаг — взять один flaky из отчёта и за 15 минут заполнить карточку: selector, readiness, initial/retry, evidence, owner/rollback. Если хотя бы одно поле неизвестно, зафиксируйте его как вопрос, а не как предположение. После этого сделайте один малый diff или соберите один недостающий артефакт. Так устойчивость тестов строится не на ожидании удачного повтора, а на проверяемом контракте пользовательского сценария.'),
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
