думаю ему мешает время исполнения. в случае селена без ресурсов на нормальную паралелизацию - разрастающаяся тест база превращает регресс в ДООООЛГОЕ дело.

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

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

Мусор надо выкидывать, не важно, мешает он или нет. Я так считаю🤷‍♂️

а завтра добавят код, который зааффектит

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

В тему об оптимизациях, слушал один интересное локальное выступление, где люди сократили регресс с 2 недель до 4 часов
В начале презентации, было заявлено, что они НЕ могут:
1) все автоматизировать
2) расширить команду
3) убрать часть тестов

Я на полном серьезе держал в голове "ничего себе, так это охренеть какие ограничения, как же вы выкрутились"
По итогу:
1) добавили автоматизацию, но не всего)
2) расширили команду, но чуть-чуть)
3) убрали часть тестов)

Это я к чему: оптимизационные задачи имеют свои входные и выходные параметры и условия. Как бы не крутились, нам придется либо усиливать все разом (как в кейсе презентации) и по чуть-чуть, либо давить на что-то одно (например, оптимизация кода тестов и прогона)

Чуда не бывает :)

иногда бывает, если сначала замедлить в 15 раз, потом можно ускорить в 15 раз =)

Это что-то на языке эффективных менеджеров, нам вроде до них далеко :)
Схема конечно крутая) Особенно если еще и время списать на "perfomance research & development" недельки 2)

все по классике: выбери из трех только два - быстро, дешево, качественно

Но этот код же добавят через задачу, задача пройдет через тесты, значит тесты можно будет дописать.
Или процесс настолько плох, что добавляют код без задач? 🤔

Хм. Не вижу связи

Изначально написали, что добавляли код, который не аффектил те места в приложении, покрытые тестами. Они-кандидаты на отключение.

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

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

Если так происходит, значит либо в задаче не указали в явном виде что затрагивает изменение, и где еще стоит проверить, либо никто не догадался до этого - повод для ретро, а не держать кучу мертвого кода тестов на случай «как бы что не случилось», которые гоняют воздух.

Разработчик может ошибиться, забыть, перепутать

А тесты - вот они, запусти их))

если бы все и всегда знали где может быть регресс...

До чего дошел регресс

Джун что ли? "в задаче не указали в явном виде что затрагивает изменение". Там даже в конторах с упоротым на это процессом в этих указаниях косячат часто, в остальных его нет. Доверия этим указаниям - нет, и быть не должно. Поэтому и есть регресс. Потому что работа тестирования - "как бы что не случилось", поэтому это должно случится на тестовой среде и как можно раньше по таймлайну цикла разработки.

З.Ы. Единственные тесты, которые отключены у нас в данный момент например - те у которых открытая джира в статусе нью или в стадии разработки/фикса. Их включит обратно автоматически, как только джиру отправят на стадию верификации

А еще привет эффект бабочки. Особенно, при тестировании монолита с кучей легаси.