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

в оснастке windows events есть события крашей браузера?

посмотрю

визуально выглядит так.
запускается тест - в диспетчере процессов появляется 6-7 процессов chrome.exe и chromedriver.exe.
Тест отрабатывает - все процессы закрываются chromedriver тоже

но какой-то момент очередной тест падает (в самом начале даже не залогинился в систему), и запущенные при его старте chrome.exe висят, хотя в хуке after стоит принудительное закрытие текущих процессов. Снимок же делается - хотя там белый лист

Вот системные события

в журнале приложение никаких ошибок

Можешь сделать минимально работающий пример и куда то выложить? Убрав секьюрные данные

Добрый день. Возможно, тема поднималась и раньше, но хочется услышать мнения о таком подходе к автоматизации, как совмещение UI и API тестов.
К примеру, отталкиваясь от того принципа, что тесты должны быть независимыми, мы пишем тесты на UI, допустим, для интернет-магазина: первый тест проверяет форму логина, второй тест проверяет, что авторизовавшийся пользователь может выбрать продукты и поместить их в корзину, третий тест проверяет, что после добавления продуктов в корзину можно осуществить оплату. Каждый последующий тест в данном примере зависим от предыдущего, и, если сломается UI тест на каком-то шаге, то все условно-зависимые тесты упадут. Допустим, API отрабатывает корректно в 100% случаях.
Можно и нужно ли переработать тесты из примера таким образом, чтобы проверялась конкретная часть UI в отдельности вне зависимости от предыдущих шагов, которые будут заменены API-запросами?

Да, допустимо, можно и нужно

Я использую разную стратегию, но стараюсь делать тесты минимально зависимыми друг от друга. Обычно я просто создаю нужное мне состояние и иду от него. Это состояние можно сделать разным способом. У меня хранится что-то в базе, а что-то вполне удобно подготовить через api.

Вот по причине отказа от зависимостей (хотя бы от UI) и подумал об некоем симбиозе, чтобы выполнять UI тесты независимо от предусловий, которые я буду делать с помощью API. Такая идея возникла после того, как некоторые тесты начали падать (открывалась не та страница/не открывалась вовсе) до осуществления основной проверки (для чего этот тест и создавался)

Да, это как раз отличный подход. Он делает тесты быстрыми и независимыми.

Более того, такой подход поможет проверять кейсы, которые достичь через UI сложно или даже невозможно.

а можете привести примеры, хотя бы самые простые?

Например вам надо проверить форму для создания объекта для которого надо чтобы существовала куча других объектов. Если их все для предусловий создавать из ui тест получится очень долгим

Ага, и тут тогда можно применить озвученный @EdwardGG подход: что-то выполнить через API, что-то взять/записать в базу и после этого выполнить основную UI-проверку. Правильно ли я понял?

Ну да,  всё верно

Всем спасибо за ответы))

но иногда лучше сделать несколько больших сквозных тестов - настоящих e2e
а остальное покрыть другими видами тестов на более низком уровне
зависит от культуры разработки в компани по большей части