{
  "index": 158,
  "slug": "editorial-2023-08-mechanism-e2e-stability",
  "title": "Почему e2e-тест проходит на retry: четыре контракта устойчивого сценария",
  "excerpt": "Timeout в e2e-тесте не объясняет причину. Разбираем locator, actionability, пользовательский результат и retry, чтобы отличать настоящий дефект от замаскированного падения.",
  "contentHtml": "<p>В CI тест нажимает «Сохранить», получает timeout, а со второй попытки проходит. В отчёте он получает статус flaky. Команда повышает timeout и закрывает задачу. Через неделю тот же сценарий снова падает на другом шаге. Цена ошибки — не только красный pipeline. Команда теряет время на повторы, пропускает дефект интерфейса или данных и привыкает считать зелёный retry доказательством исправности.</p>\n<p>Тезис простой: устойчивость e2e-теста нельзя свести к одному timeout. В сценарии действуют отдельные контракты. Locator должен выбрать нужный элемент. Actionability должна разрешить действие. Assertion должен дождаться пользовательского результата. Retry должен описать факт повторного запуска, но не объяснить его причину.</p>\n<h2>Симптом начинается раньше TimeoutError</h2>\n<p>Один текст ошибки скрывает разные события. Locator может найти ноль элементов или несколько. Кнопка может быть видимой, но перекрытой анимацией. Click может пройти, но сервер вернёт ошибку. Сохранение может завершиться, а тест будет ждать исчезновения spinner, который не связан с итоговым состоянием. Retry может запуститься в новом worker с другим состоянием данных.</p>\n<p>Первый вопрос звучит не «какой timeout поставить?», а «какой контракт не выполнен?». Разделите фазу поиска locator, фазу действия, фазу ожидания результата и фазу retry. Это сразу сужает область правки.</p>\n<h2>Четыре контракта одного теста</h2>\n<table><thead><tr><th>Контракт</th><th>Что он гарантирует</th><th>Что он не гарантирует</th></tr></thead><tbody><tr><td>Locator</td><td>Тест обращается к нужному пользовательскому элементу и ожидает понятную cardinality.</td><td>Что операция завершилась успешно.</td></tr><tr><td>Actionability</td><td>Элемент допустимо использовать: он найден, видим, стабилен, принимает события и включён.</td><td>Что приложение приняло действие или сохранило данные.</td></tr><tr><td>Readiness</td><td>После действия появился наблюдаемый пользовательский результат.</td><td>Что причина результата находится в DOM.</td></tr><tr><td>Retry</td><td>Тест повторился и получил новый outcome.</td><td>Что первая ошибка была случайной или устранена.</td></tr></tbody></table>\n<p>Playwright автоматически ждёт actionability перед действиями. Для <code>click()</code> он проверяет, что locator разрешается ровно в один элемент, элемент видим, стабилен, получает события и включён. Это защищает от клика по исчезнувшему или перекрытому control. Но проверка заканчивается, когда click допустим. Библиотека не знает, должен ли после него появиться статус «Сохранено», новая строка или ошибка.</p>\n<p>Readiness принадлежит пользовательскому сценарию. Для профиля это status с текстом «Сохранено» и новое значение поля. Для импорта — строка с terminal state. Spinner, enabled-кнопка и network idle могут быть промежуточными признаками. Они не заменяют бизнес-результат.</p>\n<h2>Учебный пример: действие и постусловие</h2>\n<p>Фрагмент ниже учебный. Он не утверждает, что такой locator или текст существуют в вашем приложении. Он показывает разделение действия и постусловия.</p>\n<pre><code>import { test, expect } from '@playwright/test';\n\ntest('user saves profile', async ({ page }) =&gt; {\n  await page.goto('/profile');\n\n  const email = page.getByLabel('Почта');\n  const save = page.getByRole('button', { name: 'Сохранить' });\n  const status = page.getByRole('status');\n\n  await email.fill('user@example.test');\n  await expect(save).toBeEnabled();\n  await save.click();\n\n  await expect(status).toHaveText('Сохранено');\n});</code></pre>\n<p>В примере <code>getByLabel()</code> и <code>getByRole()</code> описывают пользовательский интерфейс. <code>click()</code> ждёт техническую готовность кнопки. <code>toHaveText()</code> ждёт наблюдаемый итог. Если сервер отвечает ошибкой, тест должен упасть на постусловии. Если locator стал неоднозначным, ошибка должна указывать на выбор элемента. Эти отказы требуют разных исправлений.</p>\n<p>Не подменяйте постусловие ручной паузой. <code>waitForTimeout(2000)</code> иногда скрывает медленный UI, а иногда просто откладывает отказ. Не подменяйте результат исчезновением spinner, если spinner исчезает и при ошибке. Не используйте <code>force: true</code>, чтобы обойти перекрытие, пока не доказано, что перекрытие не является дефектом интерфейса.</p>\n<h2>Retry меняет условия запуска</h2>\n<p>В Playwright retry выключен по умолчанию. Если он включён, упавший тест запускается снова. Runner работает с worker-процессами. После отказа worker может быть отброшен, а повтор начнётся в новом процессе. Retry способен убрать утечку состояния, изменить порядок подготовки данных или повторить cleanup. Это наблюдение о двух запусках, а не доказательство случайности.</p>\n<p>Статус flaky полезен как сигнал: первая попытка не прошла, повторная прошла. Он не отвечает на вопросы «почему упало», «исправили ли причину» и «будет ли проходить другой браузер». Trace, записанный через <code>on-first-retry</code>, относится к повторной попытке. Он показывает конкретный запуск, но не восстанавливает контекст первой ошибки.</p>\n<p>Отрицательный путь важен не меньше зелёного. Если click прошёл, но readiness не наступил, тест должен закончиться понятной ошибкой на assertion результата. Если retry затем проходит, сохраняйте обе попытки. Нельзя заменить историю фразой «flaky исчез» без проверки данных, состояния и UI-сигнала.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Timeout на click</td><td>Locator пустой, множественный, перекрыт или disabled.</td><td>Проверьте cardinality, видимость, стабильность и получение событий.</td><td>Уточните scope и locator; исправьте UI или данные, если control недоступен.</td></tr><tr><td>Click прошёл, тест ждёт до timeout</td><td>Assertion ждёт не тот результат или UI не сообщает terminal state.</td><td>Назовите факт, который должен увидеть пользователь.</td><td>Добавьте web-first assertion на этот факт или согласуйте UI-контракт.</td></tr><tr><td>Первый запуск failed, retry passed</td><td>Утечка данных, порядок тестов, внешний сервис или скрытая готовность.</td><td>Сравните входы, worker, cleanup, номер попытки и evidence.</td><td>Изолируйте данные или исправьте ожидание. Не увеличивайте retry.</td></tr><tr><td>Тест проходит только с waitForTimeout</td><td>Сценарий не ждёт наблюдаемое событие.</td><td>Уберите паузу в учебной ветке и найдите первый пользовательский факт.</td><td>Замените паузу на locator/assertion с ясным сообщением.</td></tr><tr><td>Trace ничего не объясняет</td><td>Артефакт относится к retry, а вопрос слишком широк.</td><td>Проверьте attempt, тест, проект и момент записи.</td><td>Используйте trace как evidence одного запуска и соберите контекст initial failure.</td></tr></tbody></table>\n<figure><img src=\"/assets/editorial/2023/e2e-stability-2023-wait-contract.svg\" alt=\"Схема четырёх контрактов e2e-теста: locator, actionability, readiness и retry\" /><figcaption>Locator выбирает control, actionability разрешает действие, readiness подтверждает пользовательский результат, а retry фиксирует повтор. Asset показывает модель, а не trace реального теста.</figcaption></figure>\n<h2>Порядок разбора</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Запишите тест, браузер, шаг, номер попытки, исходную ошибку и артефакт. Формулировки «иногда падает» недостаточно.</li><li><strong>Определите фазу.</strong> Отделите поиск locator, actionability, assertion результата, подготовку данных и retry.</li><li><strong>Проверьте locator.</strong> Убедитесь, что он выражает пользовательский смысл, работает в нужном scope и возвращает ожидаемое число элементов.</li><li><strong>Назовите readiness.</strong> Запишите terminal state, который доказывает успех. Сверьте его с тем, что увидит пользователь.</li><li><strong>Сравните попытки.</strong> Сопоставьте входные данные, worker, cleanup, конфигурацию и порядок действий. Retry рассматривайте как новый запуск.</li><li><strong>Проверьте evidence.</strong> Свяжите trace, screenshot или log с попыткой. Если артефакт отсутствует, так и запишите.</li><li><strong>Сделайте один diff.</strong> Меняйте один слой: locator, assertion, изоляцию данных или evidence. Укажите owner и rollback. Timeout меняйте только после доказательства нужного события.</li><li><strong>Проверьте отрицательный путь.</strong> Ошибка сервера, отсутствие readiness и неоднозначный locator должны давать разные понятные отказы. Зелёный retry сам по себе проверкой не считается.</li></ol>\n<h2>Ограничения</h2>\n<p>Модель не делает любой тест стабильным. Locator с role/name может быть корректным, но приложение может показывать неверное состояние. Assertion может быть семантическим, но тестовые данные могут пересекаться. Retry помогает обнаружить flake, но не заменяет изоляцию и диагностику. Trace фиксирует только записанный запуск. Отдельно проверяйте версии Playwright, браузеры, сеть и внешний сервис.</p>\n<p>Учебный код не запускает реальный профиль, не измеряет flake rate и не доказывает production-результаты. Для рабочего теста подставьте реальные роли, данные и terminal state, затем проверьте их на целевой конфигурации.</p>\n<h2>Критерий готовности</h2>\n<p>Разбор готов, когда для одного сценария записаны четыре вещи: уникальный locator, ожидаемый пользовательский результат, evidence с номером попытки и действие с понятным rollback. На контролируемом отрицательном пути тест должен падать на соответствующем контракте, а не на случайном timeout. На повторном запуске команда должна видеть, что изменилось: locator, readiness, данные или окружение. Только после этого статус flaky становится входом для проверки, а не заменой объяснения.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://playwright.dev/docs/locators\" target=\"_blank\" rel=\"noopener\">Playwright: Locators</a> — locator и auto-waiting.</li><li><a href=\"https://playwright.dev/docs/actionability\" target=\"_blank\" rel=\"noopener\">Playwright: Auto-waiting</a> — actionability и auto-retrying assertions.</li><li><a href=\"https://playwright.dev/docs/test-retries\" target=\"_blank\" rel=\"noopener\">Playwright: Retries</a> — worker-процессы и категории passed/flaky/failed.</li></ul>"
}