{
  "index": 189,
  "slug": "editorial-2022-10-practice-ui-tests",
  "title": "UI-тест ждёт состояние, а не секунду",
  "excerpt": "Как заменить хрупкую паузу после действия на наблюдаемый контракт, проверить отрицательный путь и понять, когда сценарий действительно готов.",
  "contentHtml": "<p>UI-тест нажимает «Сохранить», ждёт секунду и ищет сообщение «Сохранено». На ноутбуке разработчика он проходит. На загруженном CI падает по таймауту. После увеличения паузы тест становится медленнее, но не умнее: сеть может ответить раньше, позже или ошибкой. В каждом случае одна секунда сообщает только о времени. Она не сообщает, принял ли интерфейс действие.</p>\n<p>Цена ошибки двойная. CI даёт ложный красный сигнал, а команда начинает повторять запуск и увеличивать timeout. Реальный дефект теряется среди случайных падений. Иногда тест зелёный, хотя пользователь получил старое сообщение или второй запрос. Надёжный UI-тест должен ждать факт, который видит пользователь, и проверять переход к этому факту.</p>\n<h2>Тезис: ожидать нужно наблюдаемое состояние</h2>\n<p>После действия у страницы должен быть короткий и понятный контракт. Например: поле редактируется; отправка ожидает подтверждения; изменение сохранено; сценарий требует восстановления. У каждого состояния есть владелец, доступное представление и условие перехода. Тест проверяет это представление. Он не угадывает готовность по прошедшему времени, исчезновению CSS-класса или случайной смене DOM.</p>\n<p>У контракта есть три слоя. Действие пользователя создаёт намерение. Логика приложения принимает или отклоняет переход и связывает его с конкретной попыткой. Интерфейс показывает результат через текст, роль или другое доступное наблюдение. Если один слой пропущен, тест начинает читать внутренний флаг либо ждать паузу. Оба варианта дают слабый оракул.</p>\n<h2>Механизм на простом сценарии</h2>\n<p>Рассмотрим форму с одним полем. Пользователь вводит текст и нажимает кнопку. До ответа сервера состояние должно стать <code>submitting</code>. Повторный submit в этом состоянии не создаёт вторую попытку. Ответ принимается только для текущего <code>requestId</code>. Тогда поздний ответ старой попытки не сможет показать успех поверх нового редактирования.</p>\n<p>В учебной модели ниже нет браузера, сети и таймера. Она показывает только переходы состояния. Поэтому пример нельзя выдавать за результат запуска настоящего e2e-теста. Его задача — сделать правила явными до выбора локаторов и способа управления ответом.</p>\n<pre><code>import { expect, test } from '@playwright/test';\n\ntest('сохраняет профиль после подтверждения', async ({ page }) =&gt; {\n  await page.goto('/profile');\n  await page.getByLabel('Почта').fill('user@example.test');\n  await page.getByRole('button', { name: 'Сохранить' }).click();\n\n  await expect(page.getByRole('status'))\n    .toHaveText('Отправка ожидает подтверждения');\n\n  // Тестовое окружение должно ответить именно этой попытке.\n  await expect(page.getByRole('status'))\n    .toHaveText('Изменение сохранено');\n});</code></pre>\n<p>В примере первая проверка важна не меньше второй. Она доказывает, что click привёл к состоянию ожидания, а не просто вернул управление обработчику. Вторая проверка подтверждает итог. Если приложение не показывает промежуточное состояние, это не повод добавить sleep. Сначала нужно решить, что пользователь должен увидеть во время операции.</p>\n<p>Не называйте успешным любой найденный текст. Сообщение от предыдущего действия может остаться в DOM. Связь с текущим <code>requestId</code> должна жить во внутреннем состоянии приложения: при новом submit старый статус очищается, а ответ старой попытки отбрасывается. В тесте проверяйте публичный результат — роль, доступное имя и актуальный текст, — а не сам идентификатор, если пользователь его не видит. Если локализация меняет текст, зафиксируйте отдельный стабильный контракт, но не прячьте смысл в техническом атрибуте, который понятен только тесту.</p>\n<figure><img src=\"/assets/editorial/2022/ui-tests-2022-state-contract.svg\" alt=\"Переходы формы: редактирование, отправка, сохранение и восстановление; повторная отправка во время ожидания заблокирована, устаревший ответ не меняет состояние.\" loading=\"lazy\" /><figcaption>Учебная схема отделяет действие, ожидание подтверждения, успешный ответ и восстановление. Она не показывает браузерный trace и не доказывает работу конкретного приложения.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика нестабильной UI-проверки</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>После click стоит <code>wait(1000)</code></td><td>Нет условия готовности</td><td>Назвать состояние, которое должен увидеть пользователь</td><td>Добавить status или alert и ждать его</td></tr><tr><td>Тест видит старый success</td><td>Сообщение не связано с попыткой</td><td>Очистить состояние и проверить новый requestId</td><td>Сопоставлять ответ с текущим переходом</td></tr><tr><td>Два click дают два запроса</td><td>Нет guard в состоянии отправки</td><td>Повторить действие до ответа</td><td>Заблокировать переход из <code>submitting</code></td></tr><tr><td>Поздний ответ меняет новый экран</td><td>Не отбрасывается stale reply</td><td>Передать ответ старого requestId после нового submit</td><td>Игнорировать чужой ответ и записать сигнал</td></tr><tr><td>После ошибки нечего повторить</td><td>Сбой очищает черновик</td><td>Проверить текст и доступное действие восстановления</td><td>Оставить данные, показать alert и определить retry</td></tr></tbody></table></div>\n<h2>Почему auto-retrying assertion не заменяет контракт</h2>\n<p>Playwright умеет повторно проверять web-assertion до успеха или истечения timeout. Это полезный механизм: тест не обязан угадывать задержку рендера. Но инструмент не знает, означает ли исчезнувшая кнопка сохранение, закрытие диалога или ошибку. Он также не отличит текущий ответ от старого. Неправильное условие, которое повторяется дольше, остаётся неправильным условием.</p>\n<p>Выбирайте assertion по пользовательскому факту. <code>toHaveText</code> проверяет сообщение, <code>toBeVisible</code> — наличие видимого состояния, <code>toBeDisabled</code> — запрет повторного действия. Эти проверки отвечают на разные вопросы. Не заменяйте их общим <code>isVisible()</code> в обычном асинхронном сценарии: такой вызов возвращает снимок в момент вызова и сам по себе не ждёт нужного состояния.</p>\n<p>Локатор по роли и имени обычно лучше связывает тест с доступным интерфейсом. <code>data-testid</code> остаётся допустимым для технического контейнера, сложного виджета или случая, где публичная семантика не подходит. Выбор должен быть осознанным. Не добавляйте скрытый атрибут только для того, чтобы не формулировать пользовательский результат.</p>\n<h2>Порядок действий</h2>\n<ol><li>Зафиксируйте исходный симптом: действие, текущую проверку, timeout, сообщение падения и состояние страницы.</li><li>Удалите объяснение «медленно» и назовите недостающий факт: запрос принят, отправка заблокирована, результат сохранён или ошибка объяснена.</li><li>Опишите переходы вокруг действия: исходное состояние, pending, success и recovery. Для каждого укажите владельца и видимое наблюдение.</li><li>Проверьте отрицательный путь: пустой ввод, двойной submit, отказ ответа, повтор после ошибки и поздний ответ старой попытки.</li><li>Добавьте в интерфейс одну устойчивую семантическую точку наблюдения. Согласуйте текст, роль и доступное имя с UX и доступностью.</li><li>В browser-тесте дождитесь промежуточного и конечного состояния через auto-retrying assertion. Не переносите учебную модель как доказательство работы страницы.</li><li>Запустите сценарий с контролируемым успехом и отказом. Сохраните версию браузера, окружение, команду и отчёт, если делаете вывод о стабильности.</li><li>Если контракт оказался неверным, откатите его вместе с assertion. Не оставляйте фиксированную паузу как постоянный запасной путь.</li></ol>\n<h2>Отрицательный путь и восстановление</h2>\n<p>Ошибку нельзя сводить к красному фону. Пользователь должен понять, что произошло и что можно сделать дальше. Для учебного сценария достаточно состояния <code>recovery-required</code>: черновик остаётся, успешный результат не появляется, а экран предлагает повторить операцию или вернуться к редактированию. В production причина может быть сетевой, серверной или связанной с правами. UI-тест не должен смешивать эти причины, если продукт показывает их по-разному.</p>\n<p>Rollback тоже имеет смысл только при ясном контракте. Возврат к редактированию не означает, что запрос отменён на сервере. Если сервер мог принять операцию, нужен отдельный reconciliation или повторное чтение. Поэтому тест проверяет ограниченный факт: интерфейс не объявляет успех без подтверждения и не теряет ввод при выбранном сценарии восстановления. Он не доказывает согласованность всех систем.</p>\n<h2>Ограничения</h2>\n<p>Ожидание состояния не устраняет все причины нестабильности. Тест может падать из-за неверных данных, авторизации, гонки между вкладками, недоступного сервиса или дефекта самого интерфейса. Доступное имя может зависеть от локали. Сетевой ответ может прийти дважды. Каждый такой случай требует отдельного контракта и отдельной проверки.</p>\n<p>Не объявляйте флак исправленным после одного зелёного запуска. Учебный код не даёт production-статистику. Документация инструмента объясняет поведение assertion, но не подтверждает состояние вашего приложения. Проверяемый вывод должен быть узким: «тест ждёт named state и проверяет текущий результат», а не «сценарий теперь всегда стабилен».</p>\n<h2>Критерий готовности</h2>\n<p>Сценарий готов, если после каждого значимого действия существует проверяемое состояние с понятным смыслом; assertion ждёт это состояние, а не прошедшее время; повторная отправка и устаревший ответ имеют определённый исход; ошибка оставляет пользователю объяснимый путь восстановления; локатор не скрывает отсутствие публичного результата. В отчёте отдельно указано, что проверено локально, а что подтверждено реальным browser-запуском.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://github.com/microsoft/playwright/blob/af0d2936ac6e8780214c251ff58a5e7d6eba41ca/docs/src/test-assertions-js.md\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Assertions, snapshot 07.10.2022</a> — зафиксированная версия документации описывает auto-retrying web assertions и отличие от обычных проверок.</li><li><a href=\"https://www.w3.org/TR/2022/WD-webdriver2-20221025/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: WebDriver Working Draft, 25.10.2022</a> — описывает протокол удалённого управления браузером и отделяет команды автоматизации от состояния, которое приложение показывает пользователю.</li><li><a href=\"https://www.w3.org/TR/2018/REC-WCAG21-20180605/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Web Content Accessibility Guidelines 2.1, Recommendation 05.06.2018</a> — задаёт датированную нормативную рамку для доступных имён и сообщений о состоянии; статья не заменяет аудит соответствия.</li></ul>"
}