а так помимо TDD есть и другие техники со схожей идеей.

если в разрезе TDD - я например заставляю людей в тестах делать несколько ограничений:

- для зависимостей которые возвращают какой-то результат использовать стабы, моки только для void
- если ты подменяешь реализацию контракта - подменяй реализацию ВСЕХ методов согласно контракту. Пример - size и isEmpty у коллекций - если size = 0 то isEmpty  = true. Если тебе для этого приходится подменять 50 методов - значит ты нарушил ISP. И не важно что реализации только size нужен
- стабить можно только зависимости контракт которых ты контролируешь.

этих штук уже достаточно что бы люди начали хотя бы вопросы задавать и что бы тесты небыли крупкими сильно

Взаимозаменяемые?

ну есть скажем контрактрое программирование (Design by Contract - не мог вспомнить), по факту вполне себе заменяет.

Ну оно как бы и с тдд не конфликтует

просто избыточно юзать и то и то.

Я вижу тесты как формализацию требований, плюсом их ещё и запускать можно, и регресс какой никакой дают

тут важно просто понимать что TDD это про дизайн системы, а не про "тесты".

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

потому "формализация требований, регресс" и т.д. это все ж больше про приемочные тесты.

Ну у архитектуры тоже есть требования для соответствия

"должно быть гибко должно быть охуенно". Такие требования?)

Значит они тоже могут быть формализованы и могу быть нарушены (регресс)

или ты про нефункциональные?

Вообще про явление тестов

А не про конкретные

хз о чем ты тогда