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

Три подхода

Добавить признак «страница готова»
Самый очевидный вариант — попросить фронтенд добавить некоторый признак того, что страница полностью готова к взаимодействию. Это мог быть:

• специальный DOM-атрибут;
  
• глобальный JS-флаг;
  
• служебный элемент в разметке.

Тесты могли бы просто ждать этот сигнал перед началом работы со страницей.
Идея выглядела разумной, но на практике оказалась трудно реализуемой. Фронтенд представлял собой большое SPA, которое развивала команда из 25+ разработчиков. Постоянно появлялись новые компоненты, старые переписывались, менялись цепочки загрузки данных.
В таких условиях ввести универсальный признак «страница полностью готова» означало бы фактически договориться, что все компоненты фронтенда должны сигнализировать о завершении своей асинхронной работы и делать это единообразно.
Для системы, которую активно развивает несколько десятков разработчиков, это означало бы постоянный контроль за тем, чтобы новые компоненты не нарушали этот контракт. Очевидно, что ради нужд автотестов никто бы такую дисциплину поддерживать не стал. Ожидания перед каждым действием
Далее я начал решать проблему в лоб. Перед кликами, вводом текста и проверками состояния элементов добавлялись ожидания появления или доступности нужного элемента. Для Selenium это стандартная практика, и в большинстве проектов именно так и решается проблема асинхронности интерфейса.
Однако довольно быстро стало понятно, что ожидание самого элемента не всегда решает проблему.
Типичная ситуация выглядела примерно так:
появился контейнер компонента↓тест нашёл элемент↓клик / проверка состояния↓данные компонента ещё не загрузились
С точки зрения Selenium всё корректно: элемент найден, взаимодействие выполнено. С точки зрения интерфейса — состояние страницы ещё промежуточное.
Кто-то может справедливо заметить: наличие контейнера ещё не означает, что компонент действительно отрисовался. Контейнер может появиться в DOM значительно раньше, чем в него будут подставлены данные.
Поэтому следующим шагом стала проверка внутреннего состояния компонента. То есть ожидание не просто контейнера, а конкретных элементов внутри него: текста, значений полей, кнопок, индикаторов и т.п.
Но и здесь возникла другая проблема — структура содержимого часто зависела от типа отображаемого объекта.
Например, часть интерфейса могла отображаться в двух режимах:

• полный режим
  
• упрощённый режим (например, объект имеет флаг isSimple)

В упрощённом варианте часть элементов просто отсутствовала, часть могла содержать пустые значения, а часть отображалась в другой структуре.
В итоге для корректного ожидания приходилось учитывать:

• тип объекта;
  
• допустимые отсутствующие элементы;
  
• поля, которые могут быть пустыми;
  
• поля, которые обязаны быть заполнены.

Фактически каждая такая проверка становилась небольшой конфигурацией правил для конкретного компонента. Со временем это бы превратилось в монструозную систему условий. Любое изменение во фронтенде требовало обновлять соответствующие проверки в тестах. Добавлялись новые типы объектов, менялась структура компонентов, появлялись дополнительные состояния. Смена фреймворка
Ещё один вариант — перейти на другой фреймворк, в котором механизмы ожиданий и синхронизации устроены лучше.
Сам по себе такой переход не выглядел невозможным. Основная работа с браузером была сосредоточена в центральном классе MyBrowser, так что базовый рефакторинг выглядел вполне подъёмным. Но проблема была не только в переписывании центрального класса.
Текущий запуск тестов уже был завязан на существующую инфраструктуру браузерных сессий, включая GGR и распределение части браузеров на десктопные машины. При смене фреймворка этот контур пришлось бы адаптировать заново: где-то перенастроить, где-то дописать недостающий слой маршрутизации и запуска. То есть переход затрагивал не только тестовый код, но и способ исполнения всего набора.
Но даже это не было главным риском. Главный вопрос был в другом: что именно мы получаем взамен?
Наши флаки возникали не из-за отсутствия очередного вейта, а из-за промежуточных состояний страницы. Экран собирался из нескольких независимых запросов, и в условиях перегруженной среды любой из них мог заметно задержаться. В результате элемент уже существовал в DOM, мог быть видимым и формально доступным для взаимодействия, но его конечное состояние ещё зависело от не-завершившейся асинхронной загрузки.
Именно здесь у нового фреймворка не было гарантированного преимущества. Да, инструменты вроде Playwright заявляютболее сильные встроенные механизмы синхронизации. Но я не нашёл оснований считать, что этого достаточно для нашей ситуации. Автоматические ожидания хорошо закрывают готовность элемента с точки зрения браузера, но не гарантируют, что страница уже перешла в нужное бизнес-состояние и все данные, влияющие на конкретный компонент, уже загружены.
То есть смена фреймворка требовала бы:

• рефакторинга текущего браузерного слоя;
  
• адаптации существующей инфраструктуры запуска;
  
• перепроверки большого набора тестов после миграции.

При этом она не давала ответа на главный вопрос: исчезнет ли именно тот тип флаков, который был связан с частично загруженной страницей. Поэтому этот вариант не выглядел решением с предсказуемым результатом.

Описание принципа реализации

Идея была простой: завести счётчик активных запросов.
При получении события requestWillBeSent — инкрементировать счётчик.
При получении loadingFinished или loadingFailed — декрементировать.
Если в какой-то момент счётчик равен нулю — значит, все отправленные запросы завершились и браузер не ждёт данных.
Схематично это выглядело примерно так:

CDP-событие: requestWillBeSent   →  activeRequests++
CDP-событие: loadingFinished     →  activeRequests--
CDP-событие: loadingFailed       →  activeRequests--
Network Idle = (activeRequests == 0)

С точки зрения тестового кода это выглядело как подписка на события DevTools-сессии: при создании браузера код подключался к CDP, включал домен Network, и начинал считать запросы.

Описание принципа реализации

В браузер инжектировался JavaScript-скрипт, который:

• Создавал MutationObserver, подключённый к document.body с отслеживанием дочерних элементов, атрибутов и всего поддерева.
  
• При каждом срабатывании callback записывал текущийDate.now() в глобальную переменную window._lastDomMutationTimestamp
  
• Экспортировал функцию window.getLastMutationTimestamp(), которую C#-код мог вызвать через ExecuteJavaScript.

Таким образом, из тестового кода в любой момент можно было спросить: «когда последний раз менялся DOM?» — и получить timestamp.

const observer = new MutationObserver((mutations) => {
    window._lastDomMutationTimestamp = Date.now();
});
observer.observe(document.body, {
    childList: true,    // отслеживать добавление/удаление дочерних узлов
    subtree: true,      // во всём поддереве, а не только прямых потомках
    attributes: true    // отслеживать изменения атрибутов
});
// Функция для внешнего опроса
window.getLastMutationTimestamp = () => window._lastDomMutationTimestamp;

DOM Idle определялся как ситуация, когда с момента последней мутации прошло достаточно времени — больше заданного порога (например, 500 мс). Если DOM не менялся дольше этого интервала, значит, интерфейс, вероятно, пришёл в устойчивое состояние.

На уровне C# это оборачивалось в цикл с поллингом:

while (stopwatch.Elapsed < timeout)
{
    var activeRequests = GetActiveRequestsFromCdp();
    var domIdleTime = ExecuteJs("return Date.now() - window._lastDomMutationTimestamp");
    if (activeRequests == 0 && domIdleTime >= thresholdMs)
    {
        // Страница стабильна
        return;
    }
    Thread.Sleep(pollingIntervalMs);
}

Почему именно class

Почему именно class, а не style? В нашемфреймворке все значимые изменения состояния компонента сопровождались изменением CSS-класса. Переключение видимости, смена активного таба, появление ошибки валидации, состояние загрузки — всё это выражалось через добавление или удаление классов. Атрибут style, напротив, менялся при любом пересчёте layout'а, анимациях, ресайзах, то есть постоянно, без прямой связи с загрузкой данных. Фильтрация по class давала хороший баланс: все значимые переходы состояния ловились, а основной шум — отсекался.

Примерная реализация fetch

const nativeFetch = window.fetch;
const pending = new Set();
window.fetch = function(input, init = {}) {
    const url = typeof input === 'string' ? input : input.url;
    const method = init.method || 'GET';
    // Генерируем уникальный ключ запроса
    const id = method + ':' + url + '-' + Date.now();
    // Запрос зафиксирован мгновенно -- в момент вызова, а не когда-нибудь потом
    pending.add(id);
    // Вызываем оригинальный fetch -- приложение не замечает подмены
    return nativeFetch(input, init)
        .then(response => {
            pending.delete(id);      // запрос завершился штатно
            return response;         // возвращаем оригинальный ответ
        })
        .catch(error => {
            pending.delete(id);      // запрос упал -- тоже убираем из реестра
            throw error;             // пробрасываем ошибку как обычно
        });
};

Примерная реализация для XMLHttpRequest

Для XMLHttpRequest подход тот же, но реализация чуть сложнее — нужно подменить open (чтобы запомнить URL и метод) и подписаться на события жизненного цикла:

const nativeOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url) {
    this._trackingId = method + ':' + url + '-' + Date.now();
    this.addEventListener('loadstart', () => {
        pending.add(this._trackingId);       // запрос стартовал
    });
    this.addEventListener('loadend', () => {
        pending.delete(this._trackingId);    // завершён (успешно или нет)
    });
    this.addEventListener('error', () => {
        pending.delete(this._trackingId);    // ошибка сети
    });
    this.addEventListener('timeout', () => {
        pending.delete(this._trackingId);    // таймаут
    });
    return nativeOpen.apply(this, arguments);
};

Решение прятал под спойлер

После того как фильтрация мутаций и сравнение oldValue заработали, DOM Idle наконец начал наступать. Но при отладке мне повезло встретить особый вид боли.
Автотест открывает страницу. Курсор после предыдущего действия случайно оказывается на элементе. Элемент реагирует: появляется тултип. Тултип — это DOM-узел, он добавляется в дерево. MutationObserver фиксирует мутацию. Через долю секунды тултип исчезает (курсор не двигается — и фреймворк решает его скрыть, либо открывшийся тултип закрывает место, триггерящее появление тултипа, тут я могу только предполагать). Узел удаляется из DOM — ещё одна мутация. Потом фреймворк снова решает показать тултип. Узел добавляется. Удаляется. Добавляется. Удаляется.
Цикл бесконечный. DOM генерирует события без остановки. С точки зрения системы — страница никогда не стабилизируется. А если не стабилизируется — тест не пойдёт дальше.

Первое желание — найти разработчиков и аккуратно поломать им руки. Но это, к сожалению, не решает техническую проблему.
Почему нельзя просто добавить в игнор
Второй идеей был быстрый фикс: завести список игнорируемых элементов и добавить туда тултипы. Мутации от элементов из списка — пропускать.
Но такой подход чинил бы один конкретный тест, а ослаблял бы механизм в целом. Если начать вручную игнорировать конкретные элементы, со временем этот список неизбежно разрастётся. Каждый новый «шумный» компонент — новая запись. А главное — если элемент попал в игнор, мы перестаём видеть любые его мутации, в том числе значимые. Тултип может фликать, но может и появиться один раз как результат загрузки — и это два совершенно разных сценария.
Нужно было решение, которое отличает одно от другого.
Не «что это за элемент», а «как он себя ведёт»
Ключевое наблюдение было простым: фликающий элемент — это не определённый CSS-класс или тег. Это паттерн поведения. Элемент добавляется в DOM и почти мгновенно удаляется. Потом снова добавляется. И снова удаляется. Цикл жизни — десятки миллисекунд.
Нормальный элемент появляется и остаётся. Или исчезает и не возвращается. Фликающий — мелькает.
Значит, нужно было не перечислять конкретные элементы, а определять характер мутации: если элемент добавлен и удалён за время меньше порога — это flicker, и его мутацию можно проигнорировать. Всё, что живёт дольше порога, — считается настоящим изменением.
Сигнатура. Чтобы понять, что тот же самый элемент добавился и удалился, нужен способ его идентифицировать. Прямая ссылка на DOM-узел не годится: после удаления из дерева и повторного добавления это технически другой объект. Поэтому используется сигнатура — строка, составленная из тега элемента, его классов и аналогичных данных родителя. Не идеальный идентификатор, но достаточный для детекции паттерна:

function getSignature(node) {
    if (!node || !node.parentElement) return '';
    const tag = node.tagName || '';
    const cls = node.className || '';
    const parentTag = node.parentElement.tagName || '';
    const parentCls = node.parentElement.className || '';
    return parentTag + '.' + parentCls + ' > ' + tag + '.' + cls;
}

Реестр. Для каждой сигнатуры хранится запись с двумя таймстампами: когда элемент с такой сигнатурой был добавлен и когда удалён.

const history = new Map();
function recordMutation(type, node, now) {
    const key = getSignature(node);
    if (!key) return;
    const entry = history.get(key) || { added: null, removed: null };
    entry[type] = now;
    history.set(key, entry);
}

При каждой childList-мутации, перед принятием решения о её значимости, обновляются записи для всех затронутых узлов:

for (const node of mutation.addedNodes) {
    if (node.nodeType === Node.ELEMENT_NODE)
        recordMutation('added', node, now);
}
for (const node of mutation.removedNodes) {
    if (node.nodeType === Node.ELEMENT_NODE)
        recordMutation('removed', node, now);
}

Детекция. После обновления реестра проверяем: все ли узлы в этой мутации — фликеры? Фликер — это элемент, для которого в реестре есть и added, и removed, причём между ними прошло меньше порога (например, 200 мс):

function isFlicker(node, now) {
    const entry = history.get(getSignature(node));
    if (!entry) return false;
    return (
        entry.added && entry.removed &&
        entry.removed > entry.added &&
        (entry.removed - entry.added) < flickerThresholdMs
    );
}

И финальная логика в обработчике мутаций:

const allNodes = [...mutation.addedNodes, ...mutation.removedNodes]
    .filter(n => n.nodeType === Node.ELEMENT_NODE);
const allAreFlickers = allNodes.every(n => isFlicker(n, now));
if (allAreFlickers && allNodes.length > 0) {
    return false;   // мутация целиком -- flicker, игнорируем
}
return true;         // есть хотя бы один «настоящий» узел -- мутация значима

Почему порог, а не счётчик
Может возникнуть вопрос: почему критерий — время между added и removed, а не количество повторений? Казалось бы, можно считать: если элемент добавился/удалился 5 раз за секунду — значит, фликер.
Проблема с подсчётом — в том, что нужно ждать накопления статистики. Первые два-три цикла будут пропущены, прежде чем счётчик наберёт порог. В это время DOM Idle будет сбрасываться.
Временной порог работает быстрее: уже на первом цикле added → removed за 50 мс понятно, что это не настоящее изменение интерфейса. Нормальный компонент, который появился в результате загрузки данных, не исчезнет через 50 мс.
Результат
Бесконечный тултип перестал мешать тестам. DOM стабилизировался даже при таком шуме, потому что фликающие мутации больше не сбрасывали таймстамп. А реальные изменения — появление нового блока, обновление списка, исчезновение формы — продолжали учитываться, потому что их жизненный цикл превышал порог.

Когда начинаешь использовать JS в автотестах — остановиться уже невозможно.

Проблема: поймать то, что уже исчезло
Представьте типичный сценарий. Тест нажимает кнопку «Сохранить». После этого нужно проверить два факта: что форма закрылась и что появился toast с текстом «Сохранено успешно».
Казалось бы — ничего сложного. Но на практике возникала дилемма.
После клика тесту нужно было проверить основное последствие действия: закрылась ли форма, обновилась ли таблица, появились ли данные. Это основной сценарий — его нельзя пропустить. Но пока тест занимался этими проверками, toast успевал всплыть и исчезнуть. К моменту, когда тест добирался до поиска уведомления, его уже не было в DOM.
А иногда toast вообще не нужен. Клик — проверка результата — всё. Никаких уведомлений ловить не надо.
Мы пытались решить это «в лоб»: передавали в метод клика специальный флаг — мол, после этого клика нужно ещё и забрать toast. Если флаг есть — метод сразу после клика хватал текст уведомления, прежде чем переходить к дальнейшим проверкам.
Но и это работало нестабильно. Иногда toast появлялся и исчезал именно в тот момент, когда Selenium переключался между командами. Иногда элемент формально ещё существовал, но уже находился в процессе анимации удаления. Иногда поиск просто не успевал. (За всеми этими витиеватыми формулировками скрывается просто - работало нестабильно)
Почему нельзя просто запустить отдельный поток
Логичная идея: если основной поток теста занят проверками — давайте заранее запустим параллельный поток, который будет через Selenium следить за появлением toast'а. Основной поток кликает и проверяет форму, а фоновый — караулит уведомление.
Мы попробовали. Оказалось — так не работает.
Selenium устроен так, что все команды к одной браузерной сессии проходят через один канал. Даже если вы из двух потоков одновременно отправите FindElement, они не выполнятся параллельно — они встанут в очередь.
То есть проблема была не в нашем коде, а в самой архитектуре WebDriver: один драйвер — один поток команд. Параллельно слушать DOM через Selenium невозможно в принципе.
Вывод напрашивался сам собой: не нужно ловить элемент через Selenium в момент его появления. Нужно заранее поставить ловушку внутри самого браузера — и потом спокойно проверить, что она поймала.
Идея: пусть браузер ловит, а тест читает
Решение строилось на том же принципе, что и стабилизация DOM: переложить работу, требующую параллельного наблюдения, на сам браузер.
MutationObserver внутри страницы работает асинхронно (по отношению к тесту) и ловит каждое добавление в дерево DOM — независимо от того, чем в этот момент занят Selenium. Мы просто даём браузеру задание: «записывай всё, что появляется по таким-то селекторам». А тест в любой удобный момент забирает результат.
Схема работы:

• Инициализация. При открытии страницы C#-обёртка подключает JS-скрипт. Скрипт вешает MutationObserver на document.body и начинает отслеживать добавление новых узлов, соответствующих заданным CSS-селекторам (toast-компоненты, alert-диалоги).
  
• Установка метки. Перед действием, после которого ожидается уведомление, тест вызывает SetTimestamp(). Это фиксирует текущий момент времени в JS-контексте браузера.
  
• Действие и проверки. Тест кликает кнопку, проверяет основные последствия, ждёт стабилизации — делает всё, что нужно по сценарию. В это время скрипт в фоне уже поймал toast и записал его данные в массив.
  
• Чтение ловушки. Когда тест готов — он запрашивает уведомления, появившиеся после метки. Неважно, исчез ли toast с экрана к этому моменту — данные уже сохранены.

Что делает JS-скрипт
Инициализация:

• Создать MutationObserver на document.body с параметрами childList: true, subtree: true. Больше ничего — ни attributes, ни characterData. Нас интересует только появление новых узлов.
  
• Подготовить два массива для хранения пойманных уведомлений: один для toast'ов, один для alert'ов.
  
• Подготовить WeakSet для уже обработанных DOM-элементов.

Отлов уведомлений (колбэк Observer-а):

• Из каждой мутации типа childList перебрать addedNodes.
  
• Для каждого добавленного элемента проверить: совпадает ли он (или его потомки) с одним из заданных CSS-селекторов (например, .toast-notification, .alert-dialog).
  
• Если совпал — извлечь из него текст сообщения и тип (success/danger/info) и сохранить в массив вместе с Date.now().

Защита от дубликатов (два уровня):

• По DOM-узлу: через WeakSet. Если элемент уже обработан — пропустить. Это защищает от ситуации, когда один и тот же узел попадает в несколько мутаций.
  
• По содержимому: если в массиве уже есть запись с таким же текстом и типом, и разница по времени меньше порога (например, 1000 мс) — считать дубликатом и пропустить. Это защищает от ситуации, когда фреймворк пересоздаёт контейнер уведомления: удаляет и вставляет заново. DOM-узел другой, но сообщение то же самое.

API (методы, доступные через window):

• setTimestamp(ts) — запомнить временную метку.
  
• getToastsSince() — вернуть из массива toast'ов только записи с timestamp >= сохранённая метка.
  
• getAlertsSince() — аналогично для alert'ов.
  
• clearData() — очистить массивы и сбросить метку.

По сути — это «чёрный ящик с магнитофоном»: записывает всё, что появляется, а тест потом прослушивает запись за нужный промежуток.
Использование со стороны тестов

// Ставим ловушку
tracker.SetTimestamp();
// Действие
settingsPage.ClickSaveButton();
// Основные проверки -- toast нас пока не волнует
settingsPage.AssertFormClosed();
settingsPage.AssertDataUpdatedInTable();
// Теперь спокойно читаем, что поймала ловушка
var toasts = tracker.GetToastsSince();
Assert.That(toasts, Has.Some.Property("Message").Contains("успешно сохранено"));

Между SetTimestamp() и GetToastsSince() может пройти сколько угодно времени. Toast мог появиться и исчезнуть — не важно. Данные уже в массиве.
И — никаких флагов в методе клика. Никаких «если нужен toast — передай ключ». Ловушка работает всегда, а тест решает сам, когда и нужно ли ему читать результат.