Встречал. И это всегда были или хреновые тесты или хреновая подсистема или хреновая декомпозиция и кривые связи.
Ага, т.е. к хреновому коду ещё и добавляем хреновые тесты. Больше хрени богу хрени.
Я к тому, что на первый взгляд мне кажется, что TDD показывает проблемы системы. И это хорошо.
А если его применять сначала, то кажется, что многих проблем можно будет избежать.
Но пока не поработаю плотно с этим хотя бы полгодика, не стану ничего утверждать.
Ты ведь можешь в случае правок учесть не все места, где он используется.
А какое мне дело до того, где он используется? Это независимый юнит, если по каким-то требованиям у него меняется определение, то либо новые требования / новое определение корректны для всех, либо кому-то придётся использовать старую версию или не использовать расшаренный юнит, а писать свою реализацию. Как тут поможет юнит-тест этого кода?
В юнит-тесте должны проверяться контракты юнита, которые декларируются наружу. Соответственно, поправили код, если тесты упали, значит нужно или сохранить совместимость со старыми контрактами или найти и исправить все места, где этот код используется в соответствии с новым контрактом.
