{
  "index": 159,
  "slug": "editorial-2023-08-practice-e2e-stability",
  "title": "Почему e2e-тест проходит со второго раза и что проверять вместо retry",
  "excerpt": "Flaky после retry — это симптом, а не причина. Разбираем границы locator, готовности интерфейса, изоляции данных и evidence на примере Playwright.",
  "contentHtml": "<p>Тест нажимает «Оплатить», получает ошибку на первой попытке и проходит на повторной. CI помечает его как flaky. Команда поднимает timeout, добавляет retry и закрывает pull request. Через неделю тот же тест снова падает, но уже дольше занимает очередь.</p><p>Цена ошибки — не только медленный pipeline. Retry может скрыть настоящий отказ: грязные данные, зависимость от порядка тестов, гонку после ответа API или неверный locator. Прошедшая повторная попытка создаёт ощущение исправления, хотя первый запуск так и остался необъяснённым.</p><p><strong>Тезис:</strong> стабильность e2e строится не вокруг большого timeout. Сначала нужно разделить selector, техническую готовность элемента, продуктовый результат, состояние данных и evidence конкретной попытки. Retry помогает классифицировать запуск. Он не объясняет причину.</p><h2>Что именно ждёт тест</h2><p>У одного сценария несколько ожиданий. Locator отвечает на вопрос «какой элемент нужно найти». Для <code>click()</code> Playwright дополнительно проверяет actionability: элемент должен существовать, быть видимым, стабильным, доступным для события и включённым. Это защищает от клика по скрытой или перекрытой кнопке.</p><p>Эти проверки не знают, завершилась ли операция. Кнопка может принять клик, пока запрос ещё идёт. Сервер может вернуть ошибку. Экран может показать промежуточный spinner. Поэтому после действия нужен отдельный readiness contract: наблюдаемый факт, который означает завершение сценария для пользователя.</p><p>Для платежа таким фактом может быть статус «Подтверждено». Для сохранения профиля — сообщение об успехе и новое значение в карточке. Для импорта — строка с терминальным состоянием. <code>disabled</code> и исчезновение spinner подходят только тогда, когда продуктовый контракт прямо говорит, что они означают успех.</p><p>Есть и граница данных. Если тест создаёт пользователя с фиксированным логином и не удаляет его, результат зависит от предыдущего запуска. Если два теста меняют одну корзину, retry получает другое начальное состояние. Locator и assertion могут быть правильными, а падает изоляция.</p><h2>Пример: проверяем результат, а не паузу</h2><p>Ниже учебный фрагмент для Playwright. Названия кнопки и статуса условны. Код не доказывает готовность конкретного продукта и не сообщает production-результаты. Он показывает границу между действием и постусловием.</p><pre><code>import { expect, test } from '@playwright/test';\n\ntest('подтверждает оплату', async ({ page }) =&gt; {\n  const payButton = page.getByRole('button', { name: 'Оплатить' });\n  const paymentState = page.getByTestId('payment-state');\n\n  await payButton.click();\n  await expect(paymentState).toHaveText('confirmed');\n});</code></pre><p><code>getByRole()</code> выбирает пользовательское действие. <code>toHaveText()</code> ждёт смысловой результат и повторяет проверку до assertion timeout. Такой код лучше, чем <code>waitForTimeout(1000)</code>: пауза ничего не говорит о состоянии приложения и одинаково плохо работает для быстрого и медленного ответа.</p><p>Если locator совпадает с несколькими кнопками, сначала исправляют область поиска или контракт доступной разметки. Если кнопка одна, но <code>payment-state</code> не меняется, проверяют продуктовый поток, API и состояние данных. Нельзя менять locator, assertion и timeout одновременно: после такой правки исчезает связь между симптомом и действием.</p><h2>Симптом → причина → проверка → действие</h2><div class='table-scroll'><table><caption>Короткая карта разбора нестабильного e2e-теста</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>Locator не найден</td><td>Разметка не появилась или селектор зависит от CSS</td><td>Снять число совпадений и посмотреть DOM первой попытки</td><td>Выбрать user-facing locator и сузить scope</td></tr><tr><td>Клик проходит, статус не меняется</td><td>Нет readiness condition, ошибка API или промежуточное состояние принято за успех</td><td>Проверить итоговый сигнал и ответ операции</td><td>Ждать terminal state; отдельно исправить приложение или данные</td></tr><tr><td>Первый запуск failed, retry passed</td><td>Гонка, утечка данных, порядок тестов или новый worker</td><td>Сопоставить данные, worker, шаг ошибки и evidence обеих попыток</td><td>Изолировать данные и подтвердить один источник различия</td></tr><tr><td>Тест проходит после роста timeout</td><td>Ожидание было коротким или assertion смотрит не на тот факт</td><td>Измерить время наступления названного состояния</td><td>Менять timeout только вместе с контрактом и лимитом</td></tr><tr><td>Trace есть, причина неясна</td><td>Артефакт относится к одной попытке</td><td>Проверить номер попытки и последний шаг</td><td>Сформулировать гипотезу и проверить её отдельно</td></tr></tbody></table></div><h2>Почему retry меняет картину</h2><p>Retry запускает тест снова после сбоя. В Playwright повтор может выполняться в новом worker. Это полезно для изоляции, но одновременно меняет окружение: новый браузерный контекст, новое состояние фикстур, другой порядок подготовки. Если первая попытка получила пользователя от соседнего теста, повтор может пройти только потому, что набор данных изменился.</p><p>Статус flaky описывает сочетание результатов «первая попытка не прошла, повторная прошла». Он не доказывает случайность. Он не говорит, что сеть была медленной, selector неверен или приложение сломалось. Для каждой гипотезы нужны свои признаки.</p><p>Trace, screenshot и action log тоже имеют границу. Они показывают, что происходило в записанном запуске. Trace на <code>on-first-retry</code> полезен для повторной попытки, но не превращается в запись первого отказа. Сохраняйте номер попытки рядом с артефактом и не называйте trace root-cause analysis.</p><h2>Иллюстрация разбора</h2><figure><img src='/assets/editorial/2023/e2e-stability-2023-flake-classification.svg' alt='Схема разбора e2e-сбоя через locator, readiness, retry и evidence' loading='lazy' /><figcaption>Схема разделяет четыре вопроса: найден ли элемент, наступил ли пользовательский результат, что изменил retry и к какой попытке относится evidence. Изображение иллюстрирует порядок проверки и не содержит измерений реального проекта.</figcaption></figure><p>Если locator не уникален, не обсуждают timeout. Если locator стабилен, но состояние не наступает, смотрят на readiness и ответ операции. Если обе части верны, сравнивают данные и окружение initial/retry. Только после этого решают, нужна ли настройка retry или дополнительные артефакты.</p><h2>Порядок действий</h2><ol><li>Зафиксируйте симптом: какая попытка упала, какая прошла, на каком шаге и с каким текстом ошибки.</li><li>Проверьте locator. Он должен выбирать ожидаемый пользовательский элемент в нужной области. Не принимайте <code>first()</code> как доказательство правильного выбора.</li><li>Назовите readiness condition одним предложением. Она должна описывать terminal state, а не длительность ожидания.</li><li>Сверьте assertion с этим условием. Уберите sleep, если он маскирует отсутствие постусловия. Оставьте timeout как верхнюю границу.</li><li>Сравните данные initial и retry: идентификаторы, cookies, storage, записи на сервере и порядок подготовки.</li><li>Прочитайте evidence по номеру попытки. Отделите факт от гипотезы: trace показывает шаг, но не объясняет причину состояния.</li><li>Внесите одну правку в один слой. После неё повторите сценарий в тех же условиях и сохраните критерий отката.</li><li>Если причина не подтверждена, оставьте тест в очереди разбора. Не объявляйте повышение timeout исправлением.</li></ol><h2>Ограничения</h2><p>Эта схема не гарантирует отсутствие flaky-тестов. Она не заменяет проверку backend, браузеров, сети, CI-ресурсов и тестовых данных. Playwright может ждать actionability и web-first assertion, но не может выбрать бизнес-сигнал за команду. Для сложного процесса readiness может включать несколько состояний, однако каждое должно иметь понятное сообщение об ошибке.</p><p>Учебный пример не запускался против браузера и не измеряет flake rate, latency или совместимость платформ. Синтетическая модель попыток не является production evidence. Официальная документация меняется вместе с версиями Playwright, поэтому поведение конкретного runner проверяют по версии в проекте.</p><h2>Проверяемый критерий готовности</h2><p>Разбор можно считать завершённым, если для выбранного теста записаны пять вещей: уникальный locator, наблюдаемый readiness condition, входные данные каждой попытки, evidence с номером попытки и одна подтверждённая причина различия. После правки тест проходит несколько независимых запусков без изменения timeout как единственного изменения, а отрицательный сценарий всё ещё падает на неверном результате. Если пункт отсутствует, стабильность не доказана — есть только удачный retry.</p><h2>Проверяемые источники</h2><ul><li><a href='https://playwright.dev/docs/best-practices' target='_blank' rel='noopener noreferrer'>Playwright: Best Practices</a> — официальные рекомендации по изоляции, user-facing locators, web-first assertions и trace.</li><li><a href='https://playwright.dev/docs/test-retries' target='_blank' rel='noopener noreferrer'>Playwright: Retries</a> — официальное описание retry и классификации результатов failed, flaky и passed.</li><li><a href='https://playwright.dev/docs/trace-viewer' target='_blank' rel='noopener noreferrer'>Playwright: Trace Viewer</a> — официальное описание просмотра действий, snapshots и сетевых событий trace.</li></ul>"
}