О чём говорит необходимость мокать много модулей в одном unit-тесте?

Когда в одном unit-тесте приходится мокать пять, десять или больше модулей, это почти всегда сигнал о проблемах в дизайне кода, а не о качестве самого теста. Мок — это заглушка, подменяющая реальную зависимость, и каждый мок означает, что тестируемый класс напрямую связан с ещё одним внешним компонентом.

Почему это плохо

• Сильная связанность (coupling): класс знает слишком много о других модулях, что затрудняет его переиспользование.
• Нарушение принципа единственной ответственности: если для теста нужно мокать БД, HTTP-клиент, логгер, кэш и очередь, класс, скорее всего, делает всё сразу.
• Хрупкость тестов: изменение сигнатуры любой зависимости ломает тест, даже если логика класса не менялась.
• Сложность чтения: тест превращается в длинную настройку моков, а сама проверка теряется.

Пример

Класс, который сам ходит в базу, отправляет письма и пишет в лог, требует моков для всего сразу. Если разбить его на сервисы и внедрять зависимости через конструктор, тест станет проще.

// Плохо: класс делает всё сам
class OrderService {
  create(order) {
    db.save(order);
    mailer.send(order.email);
    logger.log('created');
    cache.invalidate(order.id);
  }
}

// Лучше: зависимости внедряются, ответственность разделена
class OrderService {
  constructor(repo, notifier) {
    this.repo = repo;
    this.notifier = notifier;
  }
  create(order) {
    this.repo.save(order);
    this.notifier.notify(order);
  }
}

Что делать

1. Разделить класс на несколько с меньшей ответственностью.
2. Использовать внедрение зависимостей (DI), чтобы подменять только нужное.
3. Вынести побочные эффекты (логирование, метрики) в декораторы или middleware.
4. Проверить, не тестируется ли интеграционное поведение через unit-тест — иногда нужен другой уровень тестов.

Итог: множество моков — это не проблема теста, а подсказка пересмотреть архитектуру. Если класс требует десяток заглушек, его стоит декомпозировать, и тогда тесты станут короче, надёжнее и понятнее.