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

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

Var79или мб TDD
Это тут в общем не при чём (и скорее вредная практика). А хорошее покрытие автоматическими тестами - безусловно, имхо это скорее необходимость для хороших проектов.

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

ТDD опускает уровень тестов очень близко к реализации. Это хорошо для библиотечного кода, в котором "то, что нужно проверить" чётко локализовано в рамках метода или класса, но не годится для кода прикладного, в котором нужно проверять взаимодействие многих классов при бессмысленности проверок конкретного класса.

Var79легче писать сначала тесты, чем тесты подстраивать под имеющиеся функции,
Писать бессмысленные тесты, а потом постоянно подстраивать их под изменения - ничем не лучше.

В прикладном коде требования довольно высокоуровневы, например: "при вводе значения в поле А в поле Б должно немедленно появиться текущее НДС от этого значения". В реализации этого требования участвуют, допустим, интерфейс, бизнес-логика и БД. Можно (и может быть, нужно) протестировать функцию расчёта НДС, но этот тест ни фига не подскажет, удовлетворяется ли исходное требование. Совершенно бессмысленно тестировать, например, controller - это несложно в рамках TDD, но идиотизм. Зато нужно протестировать интерфейс, что в одно поле внесли, и в другом реально тут же появилось - но это уже делается не в рамках TDD.

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