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

monorepo? фронт и бэк в одном репозитории?

в основном что в объетках проверяемых появились/удалились ранее доступные данные

монорепа

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

у меня есть команда тестеров. Собираюсь их обучать автотестам, вопрос решит ли мою проблема идея и написанием/актуализацией автотестов в той же ветке, где сам функционал при мердже

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

просто сейчас на вскинду уже 300 тестов есть

7 из них падают к приемру, потому что изменили данные входные/приходящие

3 упали из-за багов)

но один фиг тратится время на анализ

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

вполне здравая идея: чтобы не понижать code coverage продукта, и не портить статистику упавших тестов, не нужно выпускать продукт, тесты которого вы не актуализировали. И лучше в этом случае либо делать в одной ветке, либо уже от фича-ветки которую разработчики с фичей выкатили сделать свою тест-ветку, с обновленными тестами. Тесты прошли, есть результат? тогда мерджите эту ветку в фичевую ветку. Дальше уже по готовности фиче ветки вливаете ее в основную.

ну т.е подход который вы описали правильный. но для наглядности я бы прямо от фичевой ветки сделал ветку отдельную с тестами.

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

зачем отключать тесты? что вы этим добиваетесь?

Автор вопроса хочет избежать анализа и разбирательства какие тесты упали из-за бага, а какие из-за плохого мержа 🙂

нигде автор не сказал, что тесты падают из-за плохого мерджа

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

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

специфика проекта такая, что существует глобальный обёект тикета. У которого огромное количество сущностей, типов и так далее. При каждой новой интеграции или улучшении что-то меняется) по сути нельзя выкинуть тесты, потому что они основные)