the0

каждый инстанс драйвера с браузером в своём контейнере. Так архитектура будет надёжная - они не мешают друг другу как при запуске в одной ОС - один браузер может подвиснуть забрав 100% цпу, другой отъест память, третий закрэшится, и они помешают выполниться остальным тестам. Так же архитектура будет sclalable и portable - легко добавлять/убирать ресурсы, запускать на разных машинах и в облаке, запускать на любых ОС. Так же контейнеры faltproof, можно их легко перезапускать при фейле

Параллельность достигается на уровне кода, там где "живут" инстансы драйвера. Код работает на машине отдельно от браузеров и никак не связан с инфраструктурой, он о ней попросту не знает ничего. Наживую браузеры бегают или в контейнерах. После того, как мы запросили сессию по URL хаба для RemoteDriver, ничего дальше не параллелится. Может вы имели ввиду, что очереди ваших запросов могут распределяться каким-либо балансером, типа ggr? Но это не имеет отношения к параллельности самих тестов и к тому, как это реализовано на уровне кода.

каждый инстанс драйвера с браузером в своём контейнере. Так архитектура будет надёжная - они не мешают друг другу как при запуске в одной ОС - один браузер может подвиснуть забрав 100% цпу, другой отъест память, третий закрэшится, и они помешают выполниться остальным тестам. Так же архитектура будет sclalable и portable - легко добавлять/убирать ресурсы, запускать на разных машинах и в облаке, запускать на любых ОС. Так же контейнеры faltproof, можно их легко перезапускать при фейле

Этот момент я понял, изолированность мы получили благодаря запуску браузеров в контейнерах, управляются они, допустим, селенойдом, но как это влияет на код? Создали драйвер в потоке, отправили на хаб, а что дальше меняется? В том смысле, что изменяется в описанном мной подходе если вы поднимаете браузеры в докере, а не запускаете, скажем, просто на VPS или виртуалке?

 

 

Я использую такой подход:

Отдельный класс, реализующий фабрику драйверов.
TestNG создает поток в @Before и затем я ищу "живой" драйвер используя фабрику в данном потоке. Если драйвера в потоке нет, создаю новый. Второй, третий и т.п. тесты/классы/сюты (в зависимости от ваших целей) будут получать новый инстанс драйвера для своего потока и работать в новом браузере. Сама переменная драйвера каждый раз укладывается в контейнер ThreadLocal и перед driver.quit извлекается из него же с тем, чтобы мы не "убили" случайно драйвер из соседнего потока.

Далее в конфиге хмл можно указать нужное количество потоков переменной thead-count. Ну, а сам TestNG может параллелить на том уровне, на котором вам нужно: методы/тесты/классы/сьюты (параметер parallel). По умолчанию количество потоков, если не ошибаюсь, равняется пяти.

Так вам не придется использовать @DataProvider, а параллельность будет происходить средствами самого TestNG и управляться из xml конфига. Получается гибко и удобно, особенно в случае, где в определенных сьютах вам не нужно запускать тесты параллельно (например они работают с одной и той же сущностью в приложении), а в других - необходимо.

да, такой подход к параллелизации был актуален до прихода контейнеризации

 

О какой именно инфраструктуре вы говорите? И в чем будет различие при использовании контейнеров?

Я использую такой подход:
Отдельный класс, реализующий фабрику драйверов.
TestNG создает поток в @Before и затем я ищу "живой" драйвер используя фабрику в данном потоке. Если драйвера в потоке нет, создаю новый. Второй, третий и т.п. тесты/классы/сюты (в зависимости от ваших целей) будут получать новый инстанс драйвера для своего потока и работать в новом браузере. Сама переменная драйвера каждый раз укладывается в контейнер ThreadLocal и перед driver.quit извлекается из него же с тем, чтобы мы не "убили" случайно драйвер из соседнего потока.

Далее в конфиге хмл можно указать нужное количество потоков переменной thead-count. Ну, а сам TestNG может параллелить на том уровне, на котором вам нужно: методы/тесты/классы/сьюты (параметер parallel). По умолчанию количество потоков, если не ошибаюсь, равняется пяти.

Так вам не придется использовать @DataProvider, каждый браузер будет управляться своим драйвером, а параллельность будет происходить средствами самого TestNG и управляться из xml конфига. Получается гибко и удобно, особенно в случае, где в определенных сьютах вам не нужно запускать тесты параллельно (например они работают с одной и той же сущностью в приложении), а в других - необходимо.

Как правило, в этом нет необходимости, так как промышленные прогоны не проводятся локально на ПК за которым вы работаете, а ранаются удаленно на VPS/PC или виртуальных машинах. Либо используйте Headless, как уже посоветовал вам коллега постом выше.