Есть задача запуска автотестов только для изменённого функционала (каким-то образом анализировать изменённые файлы в коммите). Запускаться должны только suite покрывающие функционал который был изменён в комите. Кто-ниюудь сталкивался с таким? В какую сторону можно почитать?

так там вроде дальше и будешь проходить фреймворк pytest

1. привести кодовую базу продукта в вид, когда бизнес логика будет бита на файлы, представляющие отдельные тестируемые сущности. (также, можно при особом упорстве выдирать название функций\классов, которые изменялись.
2. завести команду в ci\cd с запуском самописного парсера, который соберет количество тэгов, обозначающих конкретные категории тест-сьютов. Например, наличие handlebars файла в коммите может намекать на необходимость UI автотестов. То есть собирается тэг "ui".
3. запустить тестраннер на группы тестов, которые протеганы в соответствии с их зонами ответственности.

т.е. в итоге последний шаг это например

pytest -k auction and billing -m api and ui

Как-то так. Связи кода и юнит теста самые плотные, они легко запускаются любыми современными процесс-менеджерами, если пишутся как нужно из коробки. А вот интеграционные и UI — придется потратить время, чтобы логические связи привести в порядок

всем привет

ребят, подскажите как добавить паузу в таком скрипте? docker-compose up -d 'тут надо паузу' && mvn clean test

Так не помогает:
https://ru.m.wikipedia.org/wiki/Sleep
?

ага, уже нашёл, немного неправильно использовал слип, по этому не работало)

А для чего пауза?

бэк у приложухи не успевает встать, тест падает)

pytest -k auction and billing -m api and ui

интересно, кто нибудь из присутствующих эту проблему на своих проектах решал/решил?

Кому надо, те решили. Для остальных же мощностей хватает гонять всю регрессию, видимо :)

можно парсить коммит мессадж на предмет ключевых слов, которые можно определить в контракте (по функционалу например) и соот-но запускать по указанному тегу тесты

лучше из коммитов получать затрагиваемые файлы все жеж
ключевые слова - это человеческий фактор: забыл указать, указал "не так" и т.д.

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

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

ммм парсить класс файлы в дифе, парсить имя класс файла, парсить методы и функции. давайте еще ветки условий парсить?))

Первые две буквы в SOLID должны препятствовать таким ситуациям, как ты описал.

Я думаю большинство не сталкивается с такой задачей, когда ты железом не заборешь количество тестов на регрессии, в крайнем случае сам руками в ci/cd руками запустишь параметризованную сборку, отфильтровав ненужное