Size: a a a

JavaScript testing

2020 December 15

AP

Alexander Popov in JavaScript testing
аллюр есть, работает более менее
источник

HA

Hidden Account in JavaScript testing
СУТЬ:
Тесты на чистом wdio с sync в минимальной конфигурации запускаются на двух хромах (два контейнера), которые взаимодействуют между собой.

При параллелизации, нужно кратно 2 увеличивать их количество.

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

Я в нем до сих пор не разобрался. Поддерживать не могу. По сей причине до сих пор не переехали с wdio v4 на хотя бы 5-ую.

ВОПРОС:
Есть ли какое-то готовое решение, чтобы нам отказаться от этого кастомного?
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Sergey Chepets
Гайс, привет. А есть вариант использовать wdio как тест раннер, без необходимости подымать хромдрайвер?
Хз, мне кажется это сомнительная идея суппортить такое
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Sergey Chepets
во-первых из-за глобального бифора. Надо костылить предварительный билд тайпскрипта или асинхронный глобальный бифор писать на js.
во-вторых из-за джестовских ретраев и алюра

Но это я пока прорабатываю варианты.
в моке это работает
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
СУТЬ:
Тесты на чистом wdio с sync в минимальной конфигурации запускаются на двух хромах (два контейнера), которые взаимодействуют между собой.

При параллелизации, нужно кратно 2 увеличивать их количество.

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

Я в нем до сих пор не разобрался. Поддерживать не могу. По сей причине до сих пор не переехали с wdio v4 на хотя бы 5-ую.

ВОПРОС:
Есть ли какое-то готовое решение, чтобы нам отказаться от этого кастомного?
а что вы тестите
источник

HA

Hidden Account in JavaScript testing
Oleksandr Khotemskyi
а что вы тестите
Продукт, который сами и пилим.

Я мож не совсем понял вопрос, вы скорее про какую-то специфику, но я не понимаю, как ответить. Уточните, пожалуйста.
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Продукт, который сами и пилим.

Я мож не совсем понял вопрос, вы скорее про какую-то специфику, но я не понимаю, как ответить. Уточните, пожалуйста.
да, что вы тестите таким хитрым подниманием сессий? Может стоит поменять логику тестирования и как то завязатся на multiremote?
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Продукт, который сами и пилим.

Я мож не совсем понял вопрос, вы скорее про какую-то специфику, но я не понимаю, как ответить. Уточните, пожалуйста.
или отказатся от тестраннера и поднимать сессии вручную?
источник

HA

Hidden Account in JavaScript testing
Oleksandr Khotemskyi
да, что вы тестите таким хитрым подниманием сессий? Может стоит поменять логику тестирования и как то завязатся на multiremote?
А под сессиями вы тут что имеете в виду?

У нас контейнеры с браузерами перманентно подняты (руками на локале или тимсити стартует их, когда в облаке гоняем).

Wdio только сами тесты гоняет в них.
источник

BO

Boris Osipov in JavaScript testing
Hidden Account
А под сессиями вы тут что имеете в виду?

У нас контейнеры с браузерами перманентно подняты (руками на локале или тимсити стартует их, когда в облаке гоняем).

Wdio только сами тесты гоняет в них.
так причем тут js?
источник

BO

Boris Osipov in JavaScript testing
если я правильно понял проблема разобраться как поднимаются контейнеры...
источник

HA

Hidden Account in JavaScript testing
Boris Osipov
если я правильно понял проблема разобраться как поднимаются контейнеры...
Не, с этим проблем нет. Ручками на локале, ка к я писал, и командой на тимсити, которая там в пайплайне.

docker-compose up --scale chrome=XX
источник

HA

Hidden Account in JavaScript testing
щя попробую переформулировать тогда вопрос
источник

BO

Boris Osipov in JavaScript testing
ага. пока вообще ничего не понятно.
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Не, с этим проблем нет. Ручками на локале, ка к я писал, и командой на тимсити, которая там в пайплайне.

docker-compose up --scale chrome=XX
а зачем вручную поднимать контейнера с браузерами? Поднимите себе какой то селеноид, пусть он менеджит эти контейнера
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Не, с этим проблем нет. Ручками на локале, ка к я писал, и командой на тимсити, которая там в пайплайне.

docker-compose up --scale chrome=XX
источник

HA

Hidden Account in JavaScript testing
Boris Osipov
ага. пока вообще ничего не понятно.
Тесты нужно запускать пареллельно (для ускорения, а то уже за 5 часов в 1 поток выходит). В облаке же в 21 поток, получается за 20 минут.

При этом тесты такие, которые работают в паре (browserA, browserB). Они реально делают действия друг для друга. browserA чето кликает у себя на фронте, смотрит что стало. Потом смотрим, что стало в browserB. Тем самым проверяем и бэк и применение инфы  на фронте пришедшей с бэка.
Много логики на фронте, которая дублирует бэк, для потенциальной работы в оффлайне. Поэтому надо тестить и то, что юзер сделал и то, что применилось прилетевшее с сервера.

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

Количество контейнеров для теста при этом фиксированное (указывается при запуске докер композ и тот же параметр при запуске раннера, выставляется под мощности компа, на котором запускаем). Локально на своем ноуте я могу гонять максимум в 3 потока (6 контейров с хромом). В облаке, к примеру, 21 поток, то есть 42 хрома).

Надеюсь, станет понятнее.
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Тесты нужно запускать пареллельно (для ускорения, а то уже за 5 часов в 1 поток выходит). В облаке же в 21 поток, получается за 20 минут.

При этом тесты такие, которые работают в паре (browserA, browserB). Они реально делают действия друг для друга. browserA чето кликает у себя на фронте, смотрит что стало. Потом смотрим, что стало в browserB. Тем самым проверяем и бэк и применение инфы  на фронте пришедшей с бэка.
Много логики на фронте, которая дублирует бэк, для потенциальной работы в оффлайне. Поэтому надо тестить и то, что юзер сделал и то, что применилось прилетевшее с сервера.

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

Количество контейнеров для теста при этом фиксированное (указывается при запуске докер композ и тот же параметр при запуске раннера, выставляется под мощности компа, на котором запускаем). Локально на своем ноуте я могу гонять максимум в 3 потока (6 контейров с хромом). В облаке, к примеру, 21 поток, то есть 42 хрома).

Надеюсь, станет понятнее.
тогда я советую ggr+selenoid и взять multiremote в wdio
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Тесты нужно запускать пареллельно (для ускорения, а то уже за 5 часов в 1 поток выходит). В облаке же в 21 поток, получается за 20 минут.

При этом тесты такие, которые работают в паре (browserA, browserB). Они реально делают действия друг для друга. browserA чето кликает у себя на фронте, смотрит что стало. Потом смотрим, что стало в browserB. Тем самым проверяем и бэк и применение инфы  на фронте пришедшей с бэка.
Много логики на фронте, которая дублирует бэк, для потенциальной работы в оффлайне. Поэтому надо тестить и то, что юзер сделал и то, что применилось прилетевшее с сервера.

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

Количество контейнеров для теста при этом фиксированное (указывается при запуске докер композ и тот же параметр при запуске раннера, выставляется под мощности компа, на котором запускаем). Локально на своем ноуте я могу гонять максимум в 3 потока (6 контейров с хромом). В облаке, к примеру, 21 поток, то есть 42 хрома).

Надеюсь, станет понятнее.
ggr+selenoid будут за вас скейлить количество сессий браузера, запускать и убивать контейнера, и еще и юаечка и запись видео в подарок
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Hidden Account
Тесты нужно запускать пареллельно (для ускорения, а то уже за 5 часов в 1 поток выходит). В облаке же в 21 поток, получается за 20 минут.

При этом тесты такие, которые работают в паре (browserA, browserB). Они реально делают действия друг для друга. browserA чето кликает у себя на фронте, смотрит что стало. Потом смотрим, что стало в browserB. Тем самым проверяем и бэк и применение инфы  на фронте пришедшей с бэка.
Много логики на фронте, которая дублирует бэк, для потенциальной работы в оффлайне. Поэтому надо тестить и то, что юзер сделал и то, что применилось прилетевшее с сервера.

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

Количество контейнеров для теста при этом фиксированное (указывается при запуске докер композ и тот же параметр при запуске раннера, выставляется под мощности компа, на котором запускаем). Локально на своем ноуте я могу гонять максимум в 3 потока (6 контейров с хромом). В облаке, к примеру, 21 поток, то есть 42 хрома).

Надеюсь, станет понятнее.
wdio multiremote - https://webdriver.io/docs/multiremote.html

как раз фича для приложений типа чатов или мульти-юзер апликейшенов где несколько браузеров взаимодействуют друг с другом
источник