Комментарии 9
Ещё можно использовать фреймворк, который в принципе не пересоздаёт один и тот же элемент по 10 раз, а всегда использует один и тот же.. правда, это не спортивно.
Это может быть непроизводительно. Всякий виртуальный скроллинг целиком построен на удалении старых нод из DOM и добавлении новых.
https://material.angular.io/cdk/scrolling
https://svelte.dev/repl/1c36db7c1e7e4ef2bfb04874321412e5?version=3.53.1
Не всякий. Гляньте этот, например: https://mol.hyoo.ru/#!section=demos/filter=list/demo=mol_list_demo_table
Спасибо за ответ! Действительно, можно использовать разные фрейморвки, но нужно учесть факторы:
1. У каждого из них есть как свои преимущества, так и недостатки, поэтому так или иначе в каждом придется с чем-то бороться.
2. Тестовый проект может быть большим, поэтом переход на другой фреймворк и стек будет не выгоден для решения единичной проблемы.
И, вы правы, в каждой из таких задач есть "спортивная" составляющая.
А по CDP нельзя спросить у браузера, типа, он окончательно успокоился, или еще что-то думает и пережевывает? Я не знаю возможностей CDP, поэтому и спрашиваю.
Проблема давняя. А через FluentWait не пробовали? Там есть возможность добавить в игнор исключения, и встретив их, запуститься новый цикл для ожидания. Единственное, не уверен, что прокатит с Stale Element Reference Exception
Спасибо за ответ!
Видимо, немного не уловили мысль, проблема возникает как раз именно в момент действия (например, кликнуть или ввести текст). До этого, само собой, под капотом работает Fluent Wait в конфигурации которого прописаны те исключения, которые нужно игнорировать, в том числе Stale Element Reference Exception. Но суть в том, что результатом метода с Fluent Wait все равно будет IWebElement, который в таком же виде попадет в Browser.Click(), поэтому обрабатывать ошибку нужно именно в самих методах обертках над действиями и передавать в метод именно callback-функцию.
Как побороть Stale Element Reference Exception при E2E тестировании современных SPA-приложений