Я уже пытался привести примеры.

С примерами у тебя не получилось ;)

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

Тесты в этом проекте не были юнит-тестами. Это было все что угодно, интергационные или системные тесты, но не юнит-тесты. Юнит-тесты быстрые. Всегда. Если юнит-тест долго исполняется, то это с вероятностью 99% не юнит-тест и с вероятностью 1% - плохой тест (и его надо переделать)

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

Тогда ты пишешь либо самую первую версию, либо в стол.

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

Решение - не нарушать обратную совместимость.

Не совсем понятно, что ты понимаешь под "не требовать повторного тестирования"? Перед каждым релизом нужно в любом случае проводить полный тест. А вот в процессе разработки можно исходить из того, что библиотека Х работает правильно и так, как от нее ожидают проекты А, Б и С и, соответственно, в процессе разработки этих продуктов библиотека Х вообще никак не используется. Просто потому что, описанные для библиотеки Х требования (контракты) известны всем проектам и они (проекты) используют именно эти контракты.

Что нужно, чтобы все это работало:

1) Нужен контроль за версиями релизов библиотеки Х.

2) Нельзя изменять существующие контракты.

3) Можно добавлять новые контракты.

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

Если между модулами А и Б нет прямой связи, то ничего не надо передавать из А в Б ;) Что-то ты тут пытаешься мудрить ;)

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

Ну заставь дурака богу молиться ;)

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

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

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

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

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

Конечно! Так же как если ты писал этот код по Pflichtenheft, то вместе с кодом придется тебе выкидывать текст из Pflichtenheft, апдейтить Wiki и бог знает какие еще действия, чтобы обновленные код соответствовал существующей документации.