Конечно! А как может быть иначе?

Очень даже может быть иначе. Так как нет однозначных решений для всех ситуаций. Я уже пытался привести примеры.

Когда был проект "с тестами" был специальный "ночной тест" на пару часов вроде, а может и больше, уже не помню.

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

А если не существует понятия "выпустил интерфейс"?

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

еще одна интересная тема.

Есть проекты А,Б,С которые используют "стандартную" либу Х (забудем даже что их имеется несколько взаимосвязанных)

Продукты "меняются" очень неравномерно А довольно часто, Б реже, а С раз в пару лет может быть. Соответственно Х может меняться довольно часто.

Есть одно важное требование - А,Б,С должны компилироваться в любой момент времени без ошибок и не требовать повторного тестирования.

Решения?

Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости

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

Все тоже самое можно делать и с "новым" модулем + то что имплементацию можно менять как угодно, неизменным остается только "ид" команды и ее значение.

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

Одно ограничение - нет "истинного" реал тайм обмена между модулями и/или системой. Но для нас это 1-2% когда действительно надо.

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

А в чем проблема? Делаешь 2 теста:1) создаешь экземпляр декодера и пишешь в него

никакие данные никуда передавать не нужно

проблема в этом - bold & italic

Хотя теперь понял - речь о физической передаче данных.

Но тут проблема простая - юнит тесты работают, а система все равно сбоит.

Не понял, ссылочку на что?

на ООП TDD. Как начав с тестов получить структуру классов.

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

Ага, если раньше можно было было выбросить только "код", то теперь оттестированный код с тестами.