Тестовые дублёры: London против Detroit и ловушка чрезмерного мокинга

Команда мокает всё. Каждый коллаборатор в каждом юнит-тесте — это мок с expect(...).toHaveBeenCalledWith(...). Их набор — это 2400 тестов, все зелёные, 91% покрытия. Затем рефакторинг, разбивающий один сервис на два — чисто внутренняя реорганизация, поведение идентично, — за один день красит 600 тестов в красный. Ни один из них не поймал баг; они поймали лишь факт, что внутренние вызовы переместились. Хуже того, месяцем ранее реальный баг в ценообразовании уехал в продакшен с полностью зелёным набором, потому что моки возвращали заготовленные значения и никто не проверял реально вычисленную сумму. Всё это время набор измерял не то.

Пять видов дублёра и тот, что кусается

«Мок» используют как универсальный ярлык, но xUnit Test Patterns называет пять различных тестовых дублёров, и это различие решает, будет ли тест надёжным или хрупким. Dummy (пустышка) — это заглушка, которую передают, но никогда не используют. Stub (стаб) возвращает заготовленные ответы на вызовы — он подаёт состояние внутрь. Fake (фейк) — это рабочая облегчённая реализация (репозиторий в памяти вместо Postgres). Spy (шпион) записывает, как его вызывали, чтобы вы могли проинспектировать это после. Mock (мок) запрограммирован ожиданиями: он утверждает, что конкретные вызовы случились, конкретным образом, и валит тест, если их не было.

Первые четыре подают входы или наблюдают выходы; мок — единственный, кто утверждает взаимодействия, и именно отсюда берётся хрупкость. Мок вшивает структуру вызовов продакшен-кода в условие прохождения/падения теста. В тот миг, когда вы меняете, как код достигает результата — даже при идентичном наблюдаемом поведении, — ожидания мока больше не совпадают, и тест падает. Стабы и фейки так не делают; они просто подают данные и дают вам проверить конечное состояние. Хвататься за мок там, где хватило бы стаба, — это самый частый способ, которым команды производят хрупкие тесты.

London (mockist) против Detroit (classicist)

Эти две школы — реальное, поимённо названное разногласие. Школа London / mockist работает снаружи-внутрь: юнит — это один класс, вы мокаете всех его коллабораторов и тестируете, утверждая взаимодействия между объектами — что нужные сообщения были посланы в нужном порядке. Школа Detroit / classicist (также Chicago) работает изнутри-наружу: юнит — это поведение, которое может охватывать несколько настоящих объектов, вы используете настоящих коллабораторов везде, где можете, мокаете лишь то, что обязаны, и утверждаете конечное состояние, а не вызовы.

Практическое следствие — это то, что переживает рефакторинг. Classicist-тесты утверждают результаты, поэтому они позволяют беспощадный рефакторинг — вы можете свободно реструктурировать внутренности, и тест остаётся зелёным, пока результат верен. Mockist-тесты утверждают структуру вызовов, поэтому они фиксируют реализацию: они точно ловят замысел дизайна, но ломаются всякий раз, когда меняется внутреннее взаимодействие. Сила London — быстрая обратная связь по дизайну снаружи-внутрь и крошечные изолированные юниты; её режим отказа — это ровно тот день с 600 красными тестами: набор, настолько привязанный к структуре, что рефакторинг становится непомерно дорогим.

Правило границ разрешает спор

Синтез сеньора — это не «выберите школу». Это правило границ: мокайте то, что не можете запустить, используйте настоящие объекты для того, что можете. Мокайте вещи медленные, недетерминированные или с побочными эффектами, которые нельзя откатить — сеть, часы, платёжный процессор, отправитель писем, сторонний API. Для коллабораторов, которыми вы владеете и которые работают быстро и чисто, используйте настоящий объект или фейк; проверка конечного состояния поверх настоящих внутренних объектов даёт вам тест, который ломается только тогда, когда ломается поведение. Это в основном позиция classicist с дисциплиной London, применённой на краях системы, и это растворяет ловушку чрезмерного мокинга: вы никогда не мокаете объект-значение или чистый хелпер, потому что не от чего изолировать.

Решающий вопрос для любого дублёра: если я рефакторю внутренности, не меняя поведения, должен ли этот тест упасть? Если ответ «нет», вы используете мок там, где место стабу или настоящему объекту. Чрезмерный мокинг — это когда ответ «да» для тестов кода, которым вы управляете, — и это ровно то, что превращает зелёный набор в 600 красных тестов, не поймавших ни одного бага, пока реальная ошибка в ценообразовании просочилась, потому что моки возвращали заготовленные числа, которые никто никогда не сверял с реальным вычислением.