Ну вот, я и говорю, запускать тесты через итератор

А параллелить как?

если упал - всегда можно в teardown логике пополнять список тех которые упали и подставлять запуск этих тестов когда основной пул иссяк

а еще у тебя есть пул юзеров, и тебе нужно чтобы один и тот же юзер не использовался в двух тестах одновременно

про "упал – перезапустить" в питесте есть коробочное решение, это просто (если вдруг кто не знал :))

Иначе они друг друга выкинут :D (серьёзно, где-то ещё осталась такая логика?)))

Иначе они друг друга выкинут :D (серьёзно, где-то ещё осталась такая логика?)))

нет, дело не в этом

ну никита прав, какую никакую изоляцию нужно в этом случае сделать

Иначе они друг друга выкинут :D (серьёзно, где-то ещё осталась такая логика?)))

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

это как если б у нас были например 10 админов которые меняли настройки одного дашборда

потому что юзер один и тот же и запрос на бэк с его ключом идет

Это да, может быть треш на бэкенде

еще кстати есть очень простой вариант

можно сделать тупо очередь

ладно, идите в пень, полночи, я сегодня чуть не поехал на работе, а вы еще тут решили тереть за оркетсрацию тестов

спокойной

убирать пользователя из пула до начала теста

а в конце теста совать его с другой стороны очереди

добрых снов :)

но и тогда возможна гонка, наверное

Можно да, кстати, но лучше под каждого юзера поток. То есть в параллели по количеству юзеров. Но мне кажется это фигня. Слишком мало параллельно потоков

А в идеале нужно количество потоков = количество тестов :)

ничто не мешает сделать много юзеров :)

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

Два апи запроса, быстро и просто :) (

А передавать просто роль

Или набор настроек

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

да, все так) правда я не могу, потому что у меня зависимости от 5 микросервисов и настройках на них – там чтоб сгенерить пользователя и окружение нужно 10-15 запросов

поэтому использую premade чуваков

но для тестов попроще одноразовый пользователь это must have, да

10-15 запросов? Странно, у тебя наносервисы чтоли?)))

Один за ФИО, другой за роли, третий за допустимые страницы

Четвёртый за пароли :((

нет, 1 на генерацию другой на апдейт – а дальше поехали настройки сервисов, от которых зависит мой проект

Раз уж тут такая пьянка зашла - по Robotium ни у кого каких-нибудь гайдлайнов и etc не завалялось?)

ну с 15 я загнул но 10 точно есть

биллинг, проект, несколько видов подпроектов из которых нужны все

10 набирается, да

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

все так, если это нужно :) мне пока что не нужно, чутка другие задачи

Тебе же не через веб интерфейс все это делать :)

(например, перемокать все это добро)

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

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

Чтобы я мог на любой неподготовленный свежий енвайромент запустить все тесты

Чтобы я мог на любой неподготовленный свежий енвайромент запустить все тесты

докер)

Докер это просто браузер, с либами нужными питончика. Ты же не будешь в Докер засовывать скрипт который будет создавать один раз юзеров?

Тогда можно уж и написать автогенерилку :D

а, я не так тебя понял)

один раз не будешь) а так у меня и тесты и браузер живут в контейнерах, и от окружения не зависят

(если это не винда)

Селеноид юзаншь?

неа

И где хостятся докеры? AWS?

докеры на своих билд-агентах

1 контейнер с браузером влегкую тянет 4 потока тестов (считай 4 окна)

Я кстати считал, если с умом подойти и тщательно контролить, то где-то на 500 параллельных тестов на разворачивать AWS с дженкинсами и селениум гридами выходит всего долларов 700 в месяц

aws прикольный, но в нем нет нужды)

у меня не такие объемы тестов, чтобы была нужда в параллелизации по 500 потоков)

Автоскейл тестов, круто же. Каждый коммит сможешь стартовать тесты

Еще прикрутить репортинг типа reportportal и бомба

продукт не легаси, он быстро меняется, поэтому есть небольшой сьют по функциональной регрессии, а и львиная доля функционала проверяется юнитами

Интеграционки судя по твоей фразе про моканье пока на начальном этапе?

Или ты юниты туда же относишь?

А так ясен пень что не легаси, пока слава богу мало проектов на микросервисах легаси)))

юниты и интеграционные я смешиваю

ERROR: S client not available

У вас qa пишут их?

Или девелоперы часть а часть qa если видят что недостаточно?

по-разному) есть qa которые пишут юниты, в моей команде разрабы очень хороши в этом плане и пишут юниты как DOD

я ревьюю и накидываю идей

имплементировать юниты не самая моя сильная сторона, хотя если надо – могу)

ну и опять же юниты бывают разные

О, точно, надо у меня тоже внедрить ревью Юнит тестов девелоперов, а то они ревьювают друг друга тесты

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

или места где проверяются ивент лупы в ивент лупах)

У тебя бекенд на js?

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

нет, питон

asyncio :)

Он же встроен уже в питон 3,нет?

да, конечно

Был кстати опыт прикручивания репортпортала с многопоточными тестами? Например на pytest

Еще прикрутить репортинг типа reportportal и бомба

Да, был опыт, нормально заходит последняя версия

Они её асинхронной сделали

Раньше заходила страшно

у меня не было, я считаю что репорты не нужны и в Тимсити нормальный репорт :D

Просто стояла задача, но затык пошел именно из-за многопоточности, времени на разбор не было)

Эта очень полезная тула именно для автоматизаторов, ты видишь какие тесты чаще всего падают, статистику прям. Плюс падения можешь помечать типа баг продукта или надо поправить или например с инетом проблемы. А потом авто анализатор при следующем запуске их сам определит и тебе не придётся пересматривать все падения

Просто стояла задача, но затык пошел именно из-за многопоточности, времени на разбор не было)

Они прикрутили асинхронность только в этом году

Эта очень полезная тула именно для автоматизаторов, ты видишь какие тесты чаще всего падают, статистику прям. Плюс падения можешь помечать типа баг продукта или надо поправить или например с инетом проблемы. А потом авто анализатор при следующем запуске их сам определит и тебе не придётся пересматривать все падения

тимсити все это умеет – показывает статистику, flaky тесты, позволяет маркать тесты и назначить расследования и ответственных – и все из коробки

тимсити все это умеет – показывает статистику, flaky тесты, позволяет маркать тесты и назначить расследования и ответственных – и все из коробки

Блин, дженкинс убогое гавно :(

Да, по ощущениям реально полезная тулза и если с ее использовать, можно много времени сэкономить на разбор репортаж

еще он умеет в среднее время выполнения теста и сборки и кучу всего

но у меня не так много аналитики – мы больше релизим, чем анализируем)

но у меня не так много аналитики – мы больше релизим, чем анализируем)

Да вообще когда тестов штук 500+ то можно даже человека на полставки на анализ падений тестов)))

Особенно если на каждый коммит запуск тестов

у меня тестов <100 :)