DI как шов для тестов: фейки, моки и граница, которая важна

Команда гордится набором тестов OrderService: 100% покрытия, каждая зависимость замокана, всё зелёное. Затем рефакторинг, ничего не меняющий в поведении — разбиение одного метода репозитория на два — делает сорок тестов красными. Тесты не проверяли, что заказы оформляются. Они проверяли, что repo.save вызван ровно один раз ровно с этими аргументами. Шов, который дал им DI, был реальным; они лишь нацелили его не туда.

Шов — это выигрыш

Всё в этом юните — внедрение через конструктор, корень композиции, абстракции вместо new — окупается здесь. Поскольку OrderService получает PaymentGateway, а не конструирует StripeClient, тест может передать замену. Эта замена — тестовый дубль, а точка внедрения — шов: стык, где продакшен-связывание меняется на тестовое. Нет шва — нет изолированного юнит-теста. Поэтому «тестируемо ли это?» и «внедрены ли зависимости?» — почти один вопрос.

Два дубля, противоположные цели

Слово «мок» используют вольно для любой замены, но различие — весь урок:

• Стаб / фейк заменяет зависимость и поставляет состояние. Фейковый UserRepository на in-memory Map ведёт себя как реальный: сохранил пользователя — можешь прочитать обратно. Ваши проверки смотрят на результат — заказ оказался сохранён, возвращённая сумма верна.
• Мок запрограммирован ожиданиями про вызовы. Он утверждает, что payment.charge(amount) вызван один раз с этим аргументом. Ваши проверки смотрят на взаимодействие, не на исход.

Первый проверяет, что система сделала; второй — как она это сделала. Оба легитимны, но падают по-разному — и Hook это то, что бывает, когда мок используют для того, что должен был покрыть фейк.

Классицисты против лондонцев и почему это важно

Это раскол классицисты против мокистов («лондонская школа»). Мокисты мокают каждого коллаборатора и проверяют взаимодействия, так что каждый юнит тестируется в полной изоляции. Классицисты используют реальные объекты или фейки для коллабораторов, которыми владеют, и берегут моки для неудобных границ. Практическое следствие — связанность со структурой: полностью замоканный тест знает точную форму вызова своей зависимости, поэтому любой рефакторинг, сохраняющий поведение, но меняющий форму вызова, ломает тест. Это и есть баг сорока красных тестов. Тесты, проверяющие через состояние, переживают рефакторинги, ведь им важен лишь наблюдаемый результат.

Мокай на границе, фейкай то, чем владеешь

Дисциплина, избегающая чрезмерного мокания: мокай на краях системы, используй реальные объекты или фейки внутри неё. Код, которым владеешь и управляешь — доменные сервисы, твои репозитории — можно связать реальными экземплярами или in-memory-фейками, чтобы тесты упражняли настоящее взаимодействие. Мокать стоит границы, которыми не управляешь или которые не можешь позволить в тесте: платёжный шлюз, отправитель писем, часы, сторонний HTTP-вызов. Это ровно те зависимости, где хочешь утверждать «мы вызвали Stripe с этой суммой», ведь сам вызов и есть внешне видимый эффект. Шов ценнее всего именно на границе системы — где DI и важнее всего.

Чрезмерное мокание — запах дизайна

Когда юнит-тесту нужно десять моков, чтобы сконструировать субъект, проблема не в тесте — в дизайне. Класс, требующий десять коллабораторов, делает слишком много, и болезненный тест — гонец. Рефлекс сеньора — читать боль теста как обратную связь о связанности, а не как повод тянуться за бо́льшим мок-арсеналом. Трудно тестировать обычно значит трудно менять.