{
  "index": 187,
  "slug": "editorial-2022-10-field-ui-tests",
  "title": "UI-тест после клика: ждать состояние, а не время",
  "excerpt": "Как разобрать flaky UI-тест: связать действие с наблюдаемым состоянием, отсеять устаревший ответ и проверить отказ без ложного успеха.",
  "contentHtml": "<p>На прогоне формы тест заполнял поле и нажимал «Сохранить». Иногда следующий шаг не находил сообщение «Изменение сохранено», хотя клик уже состоялся. В тесте стояла фиксированная пауза: на быстрой машине её хватало, на занятом CI — нет. Увеличение паузы лишь снижало частоту падения и делало прогон дольше. Цена ошибки — недоверие к результату сборки и риск принять старый или неполный ответ за результат текущего сохранения.</p>\n<p>Первое предположение обычно звучит как «сервер медленный». Но тест в этот момент не знает, какого события ждёт. Он может проверять истёкшую секунду, исчезнувший spinner или текст, оставшийся от предыдущей попытки. Надёжный сценарий связывает действие, переход состояния, пользовательское подтверждение и отказ. Таймаут ограничивает поиск результата, но не определяет сам результат.</p>\n<h2>Сцена: что именно упало</h2>\n<p>Начните с одного конкретного падения. Зафиксируйте маршрут, исходные данные, действие, locator и последний видимый статус. Если в trace видно только клик, это ещё не объясняет причину. Запрос мог не уйти, ответ мог прийти от первой попытки, обработчик мог дважды отправить форму, а ошибка могла остаться только в консоли.</p>\n<p>Разделите проверку на два наблюдения. Клик проверяет готовность элемента к действию. После клика нужен отдельный контракт результата: например, область с ролью <code>status</code> меняет текст на «Отправка...», а затем на «Изменение сохранено». Внутреннее поле <code>phase</code> помогает приложению управлять переходом, но не является хорошим единственным объектом для e2e-проверки: пользователь его не видит.</p>\n<div class=\"table-scroll\"><table><caption>От симптома к проверяемой гипотезе</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Гипотеза</th><th scope=\"col\">Минимальная проверка</th><th scope=\"col\">Решение</th></tr></thead><tbody><tr><td>После submit стоит sleep</td><td>Не названо состояние ожидания</td><td>Посмотреть DOM и trace между кликом и ответом</td><td>Добавить pending-сигнал и ждать его</td></tr><tr><td>Старый успех проходит иногда</td><td>Ответ не связан с попыткой</td><td>Сравнить идентификатор ответа с текущим</td><td>Игнорировать stale reply</td></tr><tr><td>Два клика дают два запроса</td><td>Повторный submit не блокируется</td><td>Задержать ответ и повторить клик</td><td>Запретить переход из <code>submitting</code></td></tr><tr><td>Отказ заканчивается timeout</td><td>Нет видимого recovery</td><td>Вернуть из стенда ошибку 500</td><td>Показать ошибку и оставить черновик</td></tr><tr><td>Тест читает private flag</td><td>Проверяется деталь реализации</td><td>Сопоставить результат с UI-контрактом</td><td>Утверждать пользовательское поведение</td></tr></tbody></table></div>\n<h2>Механизм: состояние владеет результатом</h2>\n<p>Для одной попытки достаточно явно разделить четыре состояния: <code>editing</code>, <code>submitting</code>, <code>saved</code> и <code>recovery-required</code>. При submit приложение сохраняет черновик, назначает <code>requestId</code> и переходит в <code>submitting</code>. Пока этот переход не завершён, второй submit не создаёт новую попытку. Ответ разрешено применить только при совпадении его идентификатора с текущим.</p>\n<p>Такой идентификатор — проектное решение, а не требование Playwright или WebDriver. Он нужен там, где ответы могут приходить не по порядку. Если первая попытка завершилась после второй, обработчик без корреляции может показать «Сохранено» для уже неактуального текста. При несовпадении идентификатора состояние не меняется. При отказе оно переходит в recovery, а черновик остаётся доступным для исправления или повторной отправки.</p>\n<figure><img src=\"/assets/editorial/2022/ui-tests-2022-diagnosis-rollback.svg\" alt=\"Схема диагностики UI-теста: после submit форма переходит в submitting, ответ сверяется с request id, совпавший успех ведёт в saved, stale reply игнорируется, а отказ ведёт в recovery с сохранением черновика.\" loading=\"lazy\" /><figcaption>Состояние формы и ответ сервера разделены идентификатором попытки. Это учебная модель для проверки, а не trace реального браузера.</figcaption></figure>\n<h2>Маленькая модель для воспроизведения</h2>\n<p>Сначала проверьте переходы отдельно от браузера. В примере ниже обработчик не зависит от времени: он принимает только ответ для текущего состояния. Тексты сообщений и значения <code>requestId</code> — проектные, поэтому в настоящем приложении их нужно заменить на свои.</p>\n<pre><code>type Phase = 'editing' | 'submitting' | 'saved' | 'recovery-required';\n\ntype State = {\n  phase: Phase;\n  draft: string;\n  requestId?: string;\n  message: string;\n};\n\ntype Reply = {\n  requestId: string;\n  outcome: 'accepted' | 'rejected';\n};\n\nfunction applyReply(state: State, reply: Reply): State {\n  if (state.phase !== 'submitting' || state.requestId !== reply.requestId) {\n    return state;\n  }\n\n  return reply.outcome === 'accepted'\n    ? { ...state, phase: 'saved', message: 'Изменение сохранено' }\n    : {\n        ...state,\n        phase: 'recovery-required',\n        message: 'Не удалось сохранить. Черновик остался в форме',\n      };\n}</code></pre>\n<p>Состояние с <code>requestId: 'request-02'</code> должно проигнорировать ответ с <code>requestId: 'request-01'</code>: фаза останется <code>submitting</code>, а текст черновика не изменится. Ответ <code>accepted</code> для <code>request-02</code> переводит состояние в <code>saved</code>. Ответ <code>rejected</code> для той же попытки переводит его в <code>recovery-required</code>. Это и есть воспроизводимая проверка гонки, а не надежда на случайный порядок сетевых событий.</p>\n<h2>Browser-тест: задержать ответ, а не тест</h2>\n<p>Когда переходы определены, зафиксируйте их через видимый контракт. Playwright ждёт готовность элемента перед действием, а web-first assertion повторяет проверку до совпадения или истечения timeout. Поэтому задержку стоит вводить в контролируемый ответ стенда, чтобы проверить pending и success в известном порядке.</p>\n<pre><code>import { test, expect } from '@playwright/test';\n\ntest('waits for the current save result', async ({ page }) =&gt; {\n  let releaseResponse = () =&gt; {};\n  const responseReleased = new Promise((resolve) =&gt; {\n    releaseResponse = resolve;\n  });\n\n  await page.route('**/api/profile', async (route) =&gt; {\n    await responseReleased;\n    await route.fulfill({\n      status: 200,\n      contentType: 'application/json',\n      body: JSON.stringify({ ok: true }),\n    });\n  });\n\n  await page.goto('/profile');\n  await page.getByLabel('Описание').fill('черновик');\n  await page.getByRole('button', { name: 'Сохранить' }).click();\n  await expect(page.getByRole('status')).toHaveText('Отправка...');\n  releaseResponse();\n  await expect(page.getByRole('status')).toHaveText('Изменение сохранено');\n});</code></pre>\n<p>Маршрут <code>**/api/profile</code>, URL, подпись поля и тексты в этом фрагменте принадлежат учебной форме. Их нужно заменить на контракт своего стенда. Смысл примера в другом: тест сначала задерживает ответ, убеждается в pending, затем разрешает ответ и ждёт success. В нём нет <code>waitForTimeout</code>, а timeout assertion остаётся страховкой для настоящего зависания.</p>\n<h2>Отказ и устаревший ответ</h2>\n<p>Положительный путь не доказывает устойчивость. Отдельным тестом верните из контролируемого endpoint отказ и проверьте две вещи: ошибка доступна пользователю, а введённый текст не потерян. Для сообщения, которое не требует немедленного прерывания работы, подходит <code>status</code>. Существенную и срочную ошибку можно объявить через <code>alert</code>, но роль не должна подменять проектирование фокуса и способ восстановления.</p>\n<pre><code>await page.route('**/api/profile', (route) =&gt; route.fulfill({\n  status: 500,\n  contentType: 'application/json',\n  body: JSON.stringify({ ok: false }),\n}));\n\nawait page.getByRole('button', { name: 'Сохранить' }).click();\nawait expect(page.getByRole('alert')).toHaveText('Не удалось сохранить');\nawait expect(page.getByLabel('Описание')).toHaveValue('черновик');</code></pre>\n<p>Для stale reply нужен контролируемый порядок двух ответов или unit-тест функции перехода из предыдущего раздела. Не подменяйте эту проверку повторным запуском: десять удачных прогонов не создают гонку, если стенд ни разу не поменял порядок ответов. В browser-тесте также проверьте, что второй клик во время <code>submitting</code> не создаёт второй запрос; это отдельное утверждение, а не побочный эффект ожидания.</p>\n<h2>Порядок исправления</h2>\n<ol><li>Запишите исходное падение: маршрут, данные, действие, locator, assertion, timeout и последний видимый статус.</li><li>Включите trace на первом retry и проверьте DOM-снимки, сеть и последовательность действий.</li><li>Нарисуйте переходы <code>editing</code> → <code>submitting</code> → <code>saved</code> или <code>recovery-required</code>.</li><li>Назначьте владельца каждого перехода: компонент формы меняет state, транспорт возвращает outcome, интерфейс показывает status или alert.</li><li>Свяжите ответ с текущей попыткой. При несовпадении идентификатора не закрывайте форму и не показывайте успех.</li><li>Замените фиксированную паузу на web-first assertion, которое ждёт конкретный текст, атрибут или доступное состояние.</li><li>Заморозьте ответы стенда для success, отказа и перестановки ответов. Проверьте повторный submit и сохранение черновика.</li><li>После изменения сравните результат на чистых данных и в том же браузере, где возникло падение.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Эта схема не решает серверную идемпотентность, конфликт нескольких вкладок, авторизацию, кеш, ретраи транспорта и reconciliation. Если сервер принял запрос, а клиент потерял ответ, одного <code>recovery-required</code> недостаточно: может потребоваться повторное чтение или журнал операции. Решение о повторе зависит от доменного протокола.</p>\n<p>Роль <code>status</code> имеет смысл только при корректно выбранном сообщении. WAI-ARIA 1.1 описывает её как live region с advisory-информацией и ненавязчивым уведомлением; <code>alert</code> предназначен для важной, обычно срочной информации. Автотест с <code>getByRole</code> проверяет наличие заявленного интерфейсного сигнала, но не заменяет ручную проверку фокуса, клавиатуры, порядка чтения и локализации.</p>\n<p>Изменение готово, если можно воспроизвести задержанный success, отказ, повторный submit и stale reply, а для каждой ветки назвать видимый результат. Формулируйте итог узко: «тест ждёт status текущей попытки и оставляет черновик при отказе». Фраза «flaky-тест исправлен» требует отдельного измерения: версия браузера и runner, окружение, число повторов, доля падений до и после.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://playwright.dev/docs/test-assertions\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Assertions</a> — официальная документация описывает web assertions, которые повторяют проверку до выполнения условия или истечения timeout.</li><li><a href=\"https://playwright.dev/docs/best-practices\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Best Practices</a> — руководство рекомендует проверять поведение, видимое пользователю, изолировать тесты, использовать пользовательские locators и web-first assertions.</li><li><a href=\"https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C WAI-ARIA 1.1 Recommendation</a> — нормативная спецификация определяет роли <code>status</code> и <code>alert</code> и их live-region semantics; это источник для выбора доступного сигнала, но не доказательство корректности конкретного интерфейса.</li></ul>"
}