Для всех ли тестов нужны mock?

Не для всех тестов нужны моки: это инструмент для изоляции и управления зависимостями

Короткий ответ: нет, моки (mock objects) нужны не для всех видов тестов. Их использование зависит от цели тестирования, типа теста и характера зависимостей тестируемого компонента. Моки — это лишь один из видов тестовых двойников (test doubles), к которым также относятся стабы (stubs), фейки (fakes), шпионы (spies) и заглушки (dummies). Применение моков оправдано в определённых сценариях, но их избыточное или неправильное использование может привести к хрупким тестам, которые проверяют не поведение системы, а её реализацию.

Когда моки действительно нужны

Моки уместны в следующих случаях:

1. Для модульного тестирования (Unit Testing) с внешними зависимостями. Например, когда класс зависит от сетевого слоя, базы данных или стороннего SDK. Мок позволяет изолировать тестируемый код и проверить его логику без реальных вызовов API.

   // Пример: тестирование сервиса с моком сети
   protocol NetworkService {
       func fetchData(completion: @escaping (Result<Data, Error>) -> Void)
   }
   
   class DataProcessor {
       let networkService: NetworkService
       
       init(networkService: NetworkService) {
           self.networkService = networkService
       }
       
       func process(completion: @escaping (Bool) -> Void) {
           networkService.fetchData { result in
               switch result {
               case .success: completion(true)
               case .failure: completion(false)
               }
           }
       }
   }
   
   // В тесте используем мок
   class MockNetworkService: NetworkService {
       var resultToReturn: Result<Data, Error>?
       
       func fetchData(completion: @escaping (Result<Data, Error>) -> Void) {
           if let result = resultToReturn {
               completion(result)
           }
       }
   }
   
   func testProcessSuccess() {
       let mockService = MockNetworkService()
       mockService.resultToReturn = .success(Data())
       let processor = DataProcessor(networkService: mockService)
       
       var didSucceed = false
       processor.process { didSucceed = $0 }
       
       XCTAssertTrue(didSucceed)
   }
   

2. Для проверки взаимодействий между объектами. Моки могут фиксировать, сколько раз был вызван метод и с какими параметрами. Например, убедиться, что метод save был вызван ровно один раз после выполнения операции.

3. Для симуляции ошибок или нестандартных состояний, которые сложно воспроизвести с реальными зависимостями (например, сбои сети, ошибки сервера 500, нехватка памяти).

4. Для ускорения тестов, когда реальные зависимости работают медленно (базы данных, сетевые запросы, сложные вычисления).

Когда моки не нужны или даже вредны

1. В интеграционных тестах (Integration Tests) и сквозных тестах (End-to-End Tests). Здесь цель — проверить взаимодействие реальных компонентов. Использование моков свело бы на нет смысл таких тестов.

2. Для тестирования простых value-типов или pure-функций без побочных эффектов и внешних зависимостей. Например:

   // Не нужно мокировать — функция детерминирована
   func calculateDiscount(price: Double, discountPercent: Double) -> Double {
       return price * (1 - discountPercent / 100)
   }
   

3. Для тестирования UI-логики с помощью snapshot-тестов — здесь важна визуальная составляющая, а не внутренние взаимодействия.

4. Когда мок становится слишком сложным и повторяет логику реальной реализации, что часто приводит к ложным срабатываниям и усложнению поддержки тестов.

Чем можно заменить моки

• Стабы (Stubs) — предоставляют предопределённые ответы, но не следят за взаимодействиями.
• Фейки (Fakes) — упрощённые, но работающие реализации (например, in-memory база данных вместо SQLite).
• Реальные зависимости — если они быстрые, стабильные и не создают побочных эффектов в тестах.

Ключевые выводы

• Моки — это инструмент для изоляции, а не обязательный атрибут тестирования. Их стоит применять там, где это действительно упрощает тесты и делает их надёжными.
• ИзбыточноеMocking нарушает принцип тестирования поведения, а не реализации. Тесты становятся хрупкими: любое изменение кода (даже без изменения поведения) ломает тесты.
• Для iOS-разработки важно сочетать разные виды тестов: модульные (часто с моками), интеграционные (без моков или с фейками) и UI-тесты. Такой подход даёт баланс между скоростью, надёжностью и покрытием.

Правильное решение — оценивать каждый случай: если зависимость мешает тестировать ключевую логику, создаёт нестабильность или замедляет тесты, то мок уместен. В остальных случаях лучше обойтись без него.