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

на счет совметного "сожительства" системных тестов и кода - спорный вопрос. как по мне - лучше отдельно. во-первых чем меньше кода и комитов - тем проще работать (мерджи те же). во-вторых не очень безопасно... ну, например при деплое на проде случайно тесты запустили и они там нафигачили нехороших вещей))

я не говорю, что вам срочно нужно выносить тесты, нужно просто понимать возможные риски. если выгоды перевешивают риски и все участники в курсе и согласны, то можно и так оставить)

> по-моему вы все немного усложняете)

Да вот врядли :)

Я расписываю детально вот это:

> поэтому он так себя ведет - ждет interactable и прочее

на основе доков.

Чтобы - было понятно как реализовать в том числе вот это:

> Если конкретно про оверлей говорить, то просто нужно дождаться пока он пропадет, потом продолжать взаимодействие

правильно и консистентно со всем остальным ;)

Конечно, я могу где то усложнить. Но честно говоря, я начал один в один из вот этого:

> Если конкретно про оверлей говорить, то просто нужно дождаться пока он пропадет, потом продолжать взаимодействие

И уперся в кучу нюансов, связанных с тем, что я пишу тесты не на селениуме для какого то проекта, а разрабатываю целую группу портов Selenide из джава - в dotnet, python и JS. То есть контекст шире... и нужно учесть и частные случаи...

Если разработчики не поддерживают ваши тесты, то и смысла нет их запускать на более низком уровне. Это будет неэффективно. Оптимальней будет запускать точечные тесты по пул реквестам разработчиков, разворачивая окружение с изменениями  автоматически в условных докерах. Но это уже инфраструктурная задача.

ну тут, как мне кажется, главное не наворотить ненужной логики, которой нет в оригинальном Selenide
на сколько знаю, селенид просто выполняет команду селениум, отлавливает ошибку, если есть (ту же элемент нот кликабл) и, если таймаут еще не прошел, то повторяет команду. т.е. перед кликом нет проверок на interactable

хотя, могу и ошибаться, сейчас глянул бегло com.codeborne.selenide.impl.SelenideElementProxy - похоже так и есть..

Ну вот в том то и дело, что в таком случае не везде  мы получим поведение пользователя...

Это и показывает исследование выше...

Для клика все прекрасно... Ибо о клике селениум беспокоится в контексте точного воспроизведения поведения пользователя...

Для дабл кликов через экшенс - он уже этого не делает... Хотя мы ожидаем такого же поведения как от клика... Протокол явно указывает что дабл клик это низкоуровневая штука на основе которой мы сами можем построить свое поведение пользователя которое захотим. То есть оно не идёт "готовым", его надо "доготовить"... Приправ доложить по вкусу:-)

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

Из этого выводы... Если в селенидах мы ждем перезапуская клик по ошибке - все ок

Но если делаем дабл клик - то нужно дополнительно чекнуть интерактабилити да ещё и дополнительно сделать скролинтувью...

Если мы делаем ввод текста - то надо дополнительно чекать тоже интерактабилити, но при этом делать это опционально... Ибо кому то как и задумано в селениуме - захочется иметь возможность вводить текст под оверлеем...

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

ну мой посыл был в том, что если делаешь порт, то нужно делать примерно так же, как в оригинале)

Ну порт это грубо сказано) чтобы легче объяснить. От порта только стиль API. Так то цель - инструмент который максимально близко к контексту пользователя большинства приложений (либо позволяет кастомизировать) симулирует его поведение да ещё и в контексте написания текстов, то есть с фишками ориентированными на асерты, сообщения об ошибках, логинг и так далее

MacOS, M1, Docker
После двух дней битья головой об все особенности поставил всё необходимое. Python ставил через brew, затем снёс и поставил с помощью инсталятора для макоси. Запускаю тесты в рабочем проекте:
- сборка контейнеров немного медленнее, но тут хрен с ним
- сессия pytest из 130 тестов проходящая на ubuntu за ~100 сек идёт уже минут 20... всё проходит, но очень медленно... если тесты в другом проекте будут завязаны на таймаутах - в текущей ситуации всё попадает

Если кто знает в чём может крыться данная проблема - хелпаните

PS: в тестах используются заглушки(aiohttp) поднятые локально, тестируемый сервис поднят локально, бд в докере(postgres)

Зависимости:

[tool.poetry.dependencies]
python = "^3.8.5"
asyncpg = "0.21.0"
uvloop = "0.15.2"
jsonschema = "3.2.0"
orjson = "3.5.2"
yarl = "1.6.3"
defusedxml = "0.7.1"
pytz = "*"
lxml = "4.6.3"
iprpc = "0.2.3"
postgres = "3.0.0"

[tool.poetry.dev-dependencies]
sphinx = "*"
sphinx-rtd-theme = "*"
flake8 = "*"
mypy = "*"
bandit = "*"
safety = "*"
pytest-cov = "*"
pytest = "*"
pytest-asyncio = “*”

m1 говорили они, производительность, интел не нужен....

Ну пока это проблема докера и некоторого софта, который пока не адаптировали)

это мак, я в сторону сетевых вещей поглядел. докер опять таки

потому что жена пишет на котлине(не самый быстро компилируемый язычок), GUI e2e в контейнере селеноида 1600+ тестов в 1 поток спецом ради интереса гнали на буке 2020 года на m1 , они в 38 минут укладывались. а тут у вас апи 20+ минут 130 штук. дичь прям

так одно дело тесты с м1 целить на внешнее окружение, другое дело гнать на самом м1 с кучей контейнеров развернутых которые друг с другом должны на этом м1 работать

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

Всем привет, может кто то сталкивался, подскажите как сделать sout в консоль jenkins ? java + selenide

"вот где карту выдавали, в то отделение и идите"

листенер повесить на тестовые классы? от вам и будет выводить нужное в консоль. а в дженкинсе это будет по дэфолту. ибо логи сборки туда сыпятся по умолчанию

ну или логгер добавить и в нужных местах использовать. тоже вариант

Спасибо )

если сборщик gradle, то достаточно добавить --info в список свитчей