Чтобы разницу пояснить:

Выбрали, что важнее всего покрыть класс CustomerServices.

В нём 8 методов.

Подход A: у кого есть день, открывает timeboxed таск, пишет тесты на 1-2-3 метода - так что бы за 3-4 часа код прошел ревью, был смерджен и закрыт.

Подход B: ставится таск покрыть CustomerServices полностью тестами. На код ревью он идёт только когда все 8 методов покрыты.  Опыт показывает, что задача невыполнима за 1 день, то есть с вероятностью 100% будут перерывы в обработке таска.

вариант А тяжко ревьювить будет, с большой вероятностью к CustomerService уже никто никогда не вернется после того как там появятся какие-то тесты

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

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

ну так более логично, да

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

Если ближе к реальности, то тесты таки были уже, но покрытие около 10-25%, то есть фаза "хоть что-то написать для очистки совести" уже позади.

мутационное тестирование спасет мир

а вы на новую функциональность и багфиксы начали писать тесты?

Да

ну тут явно не та ситуация, тестированию время судя по всему по остаточному принципу уделяют

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

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

Да, придётся, но есть орг. воркэраунды.

Если я пишу тест - то стараюсь лучше покрыть один кейс полностью со всеми инвариантами, чем добавлю во все методы один happy path тест.

Если почему-то я придумал восемь инвариантов, но срочно нужно было уехать за молоком, и успел реализовать только 6, то оставил в коде уже заготовки (тестовый метод без реализации или хотя бы коммент TODO) - для всех 8.

Да, для этого нужна культура и дисциплина.

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

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

Иногда (по совести часто, на практике увы нет) - написание теста просто заставляет отрефакторить и сам код. Если не писать тесты и не рефакторить - то обычно вызывающие модули вносят костыли, которые долго и больно извлекать (потом они конечно остаются на всегда- "по историческим причинам").

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

И еще одна причина - в эти 3-4 часа чаще приходит идея взять новую стори и накодярить туда реализацию без тестов.

ну вот это надо пресекать

Это да.

меньше вреда будет если разраб просто эти 3-4 часа попинает, чем замержит новое говно без тестов