это в любом случае лучше чем 0 тестов

Codeceptjs

В: Как добиться стабильности динамических элементов?
О: уважать их динамизм.

Что это значит? отказаться от инициализации элементов страницы один раз при переходе на страницу. Вместо этого если ты хочешь кликать на какой-то виджет, то поиск этого динамического виджета нужно делать непосредственно перед кликом.

Сравни два куска кода

class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.login_button = self.driver.find_element_by_xpath(*login_btn_locator)  # поиск осуществился один раз

   def press_login(self): 
        self.login_button.click()  # переиспользуем уже найденное значение при инициализации э-тов пейджобьекта

и тот же по сути метод клика, но чуть измененный:

class LoginPage:
    def __init__(self, driver):
        self.driver = driver

   def press_login(self): 
         self.driver.find_element_by_xpath(*login_btn_locator).click()  #  каждый раз когда мы делаем клик происходит поиск по DOM, результат (найденный элемент) нигде не хранится

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

Т.е. задача сводится к:
- поиску элементов которые делают виджет виджетом (это должны быть уникальные элементы, чтобы ты мог верить тестам, что они нашли реально виджет. это может быть поле ввода с уникальным ID например)
- поиск элемента осуществляется перед работой с ним (т.е. между поиском элемента виджета и его кликом нет НИКАКИХ операций , которые заставят пересобирать DOM веб-страницы).

этот механизм и способ решения достаточно тривиален и на примере кода выше (Selenium) и еще выше кусочек предоставленный Андреем (selenide, java) , идея одинаковая лежит в обоих решениях

Спасибо за варианты для решения задачи с виджетом, так как я использую в своем проекте selenide + cucumber, больше подошёл вариант решения на selenide коде

https://www.youtube.com/watch?v=sHQBw1n4ZJ8
FIDDLER - Анализатор сетевого трафика
Установка, настройка. Как его использовать и для каких задач он используется.
P.S. Пользуетесь FIDDLER ?

Мне кажется ситуация с QA автоматизацией примерно такая , у нас есть супер-продвинутые фреймы на любой вкус (front,back) где можно за день развернуть маленький сайт с примитивным crud'ом.  Но парадокс в том что у нас нету нормального общепризнанного Фрейма для тестирования, что бы он работал из коробки. И селениум это просто инструмент манипуляции браузером, все равно вокруг него надо писать кучу кода. Всякие службы, ожидалки итд итп. К сожалению у нас нет решения для всех. Я думал может объеденить (конечно не под моим началом, у меня мало опыта) армии тестеров и написать общепризнанное (пусть и не идеальное) решение? Пишу не для холиваров.

Html

определи понятие "нормальный фреймворк для тестирования". чего не хватает в селениуме? можно конечно и изобретать новые вещи, но большинство существующих можно дорабатывать и дорабатывать, благо, львиная доля из них — опенсорс. Каждый раз когда чего-то не хватает или кажется что можно лучше - всегда можно завести Issue на гитхаб и получить обратную связь, может если одобрена идея будет, ее воплотят разработчики, поддерживающие этот фреймворк

"селениум это просто инструмент манипуляции браузером, все равно вокруг него надо писать кучу кода" - testproject.io бесплатен и там вроде как есть рекордер. Код писать вообще не нужно, какие-то манипуляции со страницей можно выделять в отдельные функции.

Мозги

Edit

proxy man еще очень хорош, но только на маках живет, увы

+1

Burp Suite

Proxyman

откуда у тостеров деньги на мак

proxyman или fiddler

жаль, фиддлера на мак нет

Есть - fiddler everywhere.