Стабилизация e2e в условиях деградирующей среды

[Ariless]

Паттерн с перехватом toast-уведомлений через "чёрный ящик" — один из самых неочевидных в UI-тестировании.

В Playwright та же проблема решается через page.waitForSelector или перехват через page.route, но race condition никуда не девается: toast появляется и исчезает быстрее, чем тест успевает его поймать. Особенно в CI, где браузер работает медленнее.

Мне помог другой подход — перехватывать не DOM-элемент, а сетевой запрос, который toast отображает.

Если toast показывает результат операции, можно ждать завершения запроса, а не появления элемента. Это убирает зависимость от скорости рендеринга.

Но ваш MutationObserver с буфером звучит надёжнее для случаев, когда toast не связан с конкретным запросом. Как решаете ситуацию, когда несколько toast-уведомлений появляются подряд?

[xirurr]

Да, в Selenium мы тоже сначала шли через waitFor-подход, но получили ровно ту же проблему, о которой вы пишете: иногда, а на практике довольно часто, уведомление просто не успевало быть поймано.

В моём случае архитектурно toast был именно частью требований. То есть мне важно было проверить не только то, что запрос ушёл и успешно завершился, но и то, что пользователь действительно получил визуальное уведомление об этом. Поэтому ожидание сетевого запроса для такой проверки — это всё же более низкоуровневая валидация: она подтверждает работу backend/frontend-взаимодействия, но не сам пользовательский сценарий.

Если же задача именно в том, чтобы убедиться, что интерфейс показал сообщение пользователю, то приходится ловить уже UI-событие, а не только сетевую активность.

Что касается нескольких уведомлений подряд — здесь как раз помогают массивы. Как я и писал в публикации, идея в том, чтобы держать буфер пойманных событий: отдельно для toast, отдельно для alert. За счёт этого можно сколько угодно времени держать включённым перехват, накапливать уведомления, а потом уже проверять содержимое списка:

• что нужный toast действительно появился;

• что не было лишних/неожиданных уведомлений. (вдруг)

[Ariless]

Разграничение точное - сетевой запрос подтверждает что операция завершилась, но не то что пользователь получил визуальную обратную связь. Это разные требования.

Буфер с накоплением событий - логичное решение для нескольких toast подряд. В Playwright делаю похоже: page.route() с счётчиком вызовов для stateful сценариев, где важен порядок событий, а не только факт появления.