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

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

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

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

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

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

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

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

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

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

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

Шов также покупает порядки величины в скорости тестов, и именно поэтому он меняет то, как работает команда. In-memory-фейк репозитория на Map разрешает save-and-read за единицы микросекунд; тот же тест против реального Postgres — даже локального — платит за установку соединения плюс сетевой round-trip, обычно по 1–10мс, плюс очистку на каждый тест. Этот разрыв накапливается: набор из 500 юнит-тестов на фейках завершается заметно меньше чем за секунду и гоняется на каждое сохранение; те же 500 против реальной базы — это задача на секунды-минуты, которую запускаешь один раз перед пушем. DI — это то, что позволяет основной массе тестов оставаться на быстрых фейках, пока тонкий слой интеграционных тестов упражняет реальную границу — получаешь миллисекундный внутренний цикл и всё равно проверяешь связывание. Компромисс, в котором нужно быть честным: фейки могут дрейфовать от поведения реальной зависимости (in-memory-Map не обеспечит уникальный constraint и не покажет deadlock), поэтому быстрые фейки не заменяют небольшой набор тестов на реальной границе — они позволяют написать гораздо больше дешёвых.

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

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