а значит все методы элемента у тебя есть

то что твоя IDE их не отрезолвила и не отобржает это не значит что их нет

Просто тогда ругается на то, что element not interactable

это уже другой вопрос, не относящийся к синтаксису

Аа

хочешь кликать, а ждешь только появления

Ладно, почитаю про element not interactable, пока не сильно силен в этих исключениях всех(

появление - это наличие в DOM

наличие в DOM - не гарантирует возможность клика

в общем иди разбирайся)

Просто не пойму, как в примере это могло работать))
https://www.geeksforgeeks.org/explicit-waits-in-selenium-python/

Или тут ошибка реально

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

в конце концов возможно ты банально ищешь не то по чему реально можно кликнуть

Да не, это правильный css селектор элемента, т.к я до этого использовал для ожидания implicitly_wait(), но прочитал статью, что оно задается только 1 раз в коде теста и лучше использовать его в других случаях, а в моем случае лучше юзать WebDriverWait

Т.е до этого по элементу успешно кликало

Значит неправильное ожидание выбираешь. Так же есть wait until clickable

Может и не правильное(, спасибо, попробую разобраться

Вопрос удаления сущностей которые были созданы во время теста (скажем, employee).
Не в каждом тесте создаётся employee, а если и создаётся, для удаления нужно связанные сущности, которые могли быть ему присвоены (зависит от теста), также удалить.
У меня возникает вопрос: необходимо ли создавать фикстуры под каждый тест, где будет удаляется буквально то что было в тесте создано (что выглядит не очень при большом их количестве). Или подобные проблемы решаются за счёт какой-то общей фикстуры которая сбрасывает всё к первоначальному состоянию.
Подскажите в каком направлении смотреть или, возможно, я не так себе представляю вообще суть проблемы.
Спасибо

Видел где то Entity Driven Testing подход, когда ты создаешь еще дополнительный слой с сущностями, в котором прописываешь какой нибудь класс пользователя  и логику конструктора и деструктора, чтобы в тесте все было чисто и понятно, но в продакшне не применял и не пробовал на пет проекте(

Многое зависит от стратегии подготовки данных: БД или АПИ. В случае с АПИ, удалять данные после выполнения теста не всегда просто, поскольку если тест все же найдёт баг (или упадёт по другим причинам), мы не понимаем, в каком именно состоянии находятся наши сущности, чтобы принимать однозначное решение об их очистке + особенности самого приложения, масштабирование и т.п. могут добавить доп. трудностей. Тут оптимальным из моей практики является очистка всех сущностей с привязкой к юзерам или до или после непосредственного запуска всех тестов, т.к. в данном случае нам не нужно хранить ссылки на рабочие объекты, мы просто чистим все, что есть. Главное тут - либо полностью изолировать окружение, либо не позволять джобам запускаться в параллель, иначе одна начнёт подтирать данные другой. С БД, с одной стороны, все проще: накатил дамп и вперёд. Но с другой, поддерживать такое решение может быть куда сложней, чем в случае с АПИ.