Mancuso S. Does TDD Really Lead to Good Design? // 2018.
https://www.youtube.com/watch?v=KyFVA4Spcgg

@tdd-as-workflow:TDD как рабочий процесс

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

@classicist-tdd:Классический TDD

Классический TDD отлично подходит для алгоритмов с ограниченным набором данных, которые можно подать на вход (то есть, без сложных зависимостей). Зависимости допускаются, если они могут быть включены в родительский класс, не нарушая SRP (то есть, это тип связи Composition). В этом случае весь граф таких зависимостей может рассматриваться как один модуль (unit) с точки зрения тестирования, подменять зависимости “поддельными реализациями” не нужно.

@outside-in-tdd:Подход “снаружи-внутрь”

Подход “снаружи-внутрь” приемлем для сложных бизнес-фич, так как позволяет (точнее, заставляет) принимать проектные решения относительно интерфейсов и объема делегирования перед написанием первых тестов. Он стимулирует разделение системы по слоям и может использоваться тогда, когда зависимости агрегируются с исходным классом (то есть, их нельзя просто включить в один класс, не нарушив SRP). В этом подходе активно используются “поддельные реализации” (mocks), так как это - эффективный инструмент проектирования.

@abstraction-layers:Уровни абстракции

Матрешка абстракции - это одна большая матрешка, в которой находится одна матрешка поменьше, а не 10 одинаковых маленьких матрешек. То есть, если класс требует инъекции десяти других классов, скорее всего, это говорит о том, что дизайн слишком резко снижает уровень абстракции. Вероятно, какие-то из этих десяти классов могут быть объединены, чтобы сделать понижение уровня абстракции более плавным и согласованным.

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