Получается в среднем по больнице около 35 секунд на тест. А вы при этом как-то выбираете какие тесты гонять на ПР, а какие на релиз кандидат?

У нас просто сейчас 490 и в 20 потоков они ходят за 5 минут (тут уже заоптимизированно все что можно, практически). И они гоняются на любой ПР. Ну и понятно, что с ростом теста это время будет только увеличиваться. Остается либо масштабироваться железом, либо делать какие-то потуги в область умного управления тестами (если потрогали то, то запусти такие-то).

Было интересно узнать как кто решает эту задачу.

То сколько браузеров при ране запускаешь?

20?

спасибо большое за идею!

Привет всем, а может такое кто-то решал?
Ignoring uncaught error WebDriverError: unknown error: Chrome failed to start: exited normally

Ага, сейчас запускается столько браузеров, сколько потоков

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

Ага, с пирамидой тестирования все понятно. У нас и юниты и интеграционные тесты пилятся не менее активно. И разработчики у нас пишут и поддерживаю тесты. Но у нас так же и достаточно большой набор функциональности разных веб-приложений. Те тесты, что есть сейчас браузерные - это часть необходимых базовых сценариев, которые требуют покрытия, а не покрываются потому что "по-другому не умеем". Но в любом случае достигаешь какого-то предела железа.

Было бы интересно послушать есть ли кто у кого нет ручного тестирования, большая часть на автотестах и как у них устроены процессы CI/CD при "большом" количестве тестов (в контексте веб-проектов).

Иногда проще и дешевле мануальщика на это дело взять, дополнительно.

Есть ещё мнение что идти вниз плохо,а вверх хорошо по пирамиде)

ну вот у нас CI/CD до стейджинга автоматом и в продакшен пару раз в день по кнопке. Ручного регресионного тестирования нет совсем. Тестрируем все что можно до того как код попадает в мастер (на уровне PR-ов). У нас не микро-сервисы, но и не монолит (что-то посередине, well-sized services я бы скорее сказал). В самом большом фронтенд проекте браузерных тестов штук 90 сейчас и бегут они на CI за 15 минут на 5 m5.xlarge инстансах (bottleneck в генерации тестовых данных, установке зависимостей, webpack сборке фронта и поднятии кучи контейнеров локально). Добавления шардов не сильно помогает, потому что минимум 8 минут CI джобы уходит на (yarn install, docker-compose up, wait for services to start, webpack build). Так как билд агенты постоянно свежие.

ага https://kentcdodds.com/blog/write-tests

ну вот кстати для проекта который представляет собой REST API service у нас девелоперы пишут тесты только на уровне send http request -> verify http response (веб сервер поднимается на локалхосте). Юнит тесты не пишут - потому что обычно при любом рефакторинге их приходится фиксить

так как это NodeJS + NPM, то большая часть логики какой-то (всякие там express middleware, domain libraries, etc) вынесены в отдельные NPM пакеты которые покрываются тестами на уровне того АПИ который они предоставляют

У нас 15 браузеров и 350 тестов на протракторе и бегают больше часа
Но у нас они длинные

круто

Топ-оф-зе-топ 🔥💪🏻

Да, оказалось если в проекте с wdio хоть где то импортируется protractor - он как то манкипатчит https и вдио не может сконектится

Пока не отбираем, просто гоняем все

Как на уровне ПР решаете что покрыть, а что нет? И как принимает в этом участие QA? Какой у вас ttm для фичи (тут, конечно, фича-фиче рознь, но все же)?