Удобно в случае, если вам нужно запускать тесты параллельно, с использованием разных браузеров и OS, с разными переменными окружения, например, или версиями какой-нибудь синтегренной к приложению внешней библиотеки. В контейнере работает для этих целей тот же Selenium Grid.
Jenkins можно соответственно разворачивать там же, в контейнере. Но можно и не делать так.
Тесты можно не заворачивать в имейдж, но ранать их внутри него.
Пример - CI построенный на TeamCity, где на куче агентов ранаются джобы, в том числе и тесты.
Доступа к настройке окружения на агенте у тебя нет - можно либо оформлять кучу заявок на установку нужного тебе ПО, потом терзать инженеров, чтобы они донастроили то что тебе нужно, либо создать доккер имейдж настроенный как тебе надо, и ранать свои тесты внутри этого контейнера. Сам код тестов при этом каждый запуск пуллится непосредственно внутри контейнера, т.е хранится все по отдельности - код в своем репозитории, доккер в своем
В каждой CI есть возможность настроить агенты-контейнеры.
Они поднимаются в контейнере с git и другими приложениями пробрасывают сокет докера с хост машины, либо сами с докером внутри. А внутри контейнера уже разворачиваются еще контейнеры стенда - называется DockerInDocker (DinD).
Подкажите, с Selenide удобно использовать TestContainers?
С TestContainers удобно использовать как Selenide так и Selenium. Просо нужно из контейнера получить ссылку на remote web driver и записать в конфиг Селенида, например так Configuration.remote = "http://" + browser.host + ":" + browser.firstMappedPort
и все. Далее все будет происходить внутри контейенера.
А образ можно использовать например такой new BrowserWebDriverContainer<>(DockerImageName.parse("selenium/standalone-chrome:4.1.0"))
- он будет сразу с Хромом внутри и хромд-райвером под 4-ый селениум. Пример для Kotlin: selenide-pages/TestConfiguration.kt at main · kochetkov-ma/selenide-pages · GitHub