Может ли использование простого экземпляра привести к проблемам в тестировании?

Влияние простых экземпляров на тестируемость в iOS-разработке

Да, использование простых экземпляров (plain instances) напрямую в коде может существенно осложнить модульное тестирование (unit testing), интеграционное тестирование и поддержку кода в долгосрочной перспективе. Под "простыми экземплярами" здесь понимаются непосредственные создания объектов через конструкторы или фабричные методы внутри классов, без использования абстракций или инверсии управления.

Основные проблемы при тестировании

1. Жёсткая связность (tight coupling)

   // Проблемный код
   class DataProcessor {
       private let networkService = NetworkService() // Простой экземпляр
       
       func process() {
           let data = networkService.fetchData() // Тестирование невозможно без реальной сети
           // обработка данных
       }
   }
   
   // Тест становится невозможным
   func testDataProcessor() {
       let processor = DataProcessor()
       processor.process() // Выполнит реальный сетевой запрос!
   }
   

2. Невозможность изоляции тестируемого компонента

   • Зависимости создаются внутри класса, что нарушает принцип Dependency Injection
   • Тесты превращаются в интеграционные, даже когда нужны юнит-тесты
   • Невозможно подменить реальные сервисы моками (mocks) или стабами (stubs)

3. Проблемы с воспроизводимостью тестов

   • Сетевые запросы могут давать разные данные
   • Работа с файловой системой или БД создаёт побочные эффекты
   • Тесты становятся недетерминированными

Решения для улучшения тестируемости

1. Внедрение зависимостей (Dependency Injection)

   // Улучшенная версия
   protocol NetworkServicing {
       func fetchData() -> Data
   }
   
   class DataProcessor {
       private let networkService: NetworkServicing
       
       // DI через инициализатор
       init(networkService: NetworkServicing) {
           self.networkService = networkService
       }
       
       func process() {
           let data = networkService.fetchData()
           // обработка данных
       }
   }
   
   // Mock для тестирования
   class MockNetworkService: NetworkServicing {
       var testData: Data?
       
       func fetchData() -> Data {
           return testData ?? Data()
       }
   }
   
   // Теперь тестируемо
   func testDataProcessor() {
       let mockService = MockNetworkService()
       mockService.testData = Data("test".utf8)
       
       let processor = DataProcessor(networkService: mockService)
       processor.process()
       // Проверяем результат без реального сетевого запроса
   }
   

2. Использование фабрик или протоколов

   // Через фабричный метод
   class DataProcessor {
       private let networkService: NetworkServicing
       
       init(networkService: NetworkServicing = NetworkService()) {
           self.networkService = networkService
       }
   }
   
   // В продакшене
   let processor = DataProcessor() // Использует реальный NetworkService
   
   // В тестах
   let testProcessor = DataProcessor(networkService: MockNetworkService())
   

3. Применение Service Locator или DI-контейнеров

   • Использование Swinject, Needle или других DI-фреймворков
   • Позволяет централизованно управлять зависимостями

Практические рекомендации

Для нового кода:

• Всегда проектируйте классы с поддержкой DI через протоколы
• Используйте внедрение зависимостей в инициализаторах
• Создавайте протоколы даже для внутренних зависимостей

Для легаси-кода:

• Рефакторинг постепенно, начиная с наиболее критичных компонентов
• Использование Adapter pattern для обёртки существующих классов
• Поэтапное введение протоколов и моков

Пример рефакторинга

// Было
class PaymentProcessor {
    private let paymentGateway = StripeGateway() // Жёсткая привязка
    
    func makePayment(amount: Double) {
        paymentGateway.charge(amount: amount)
    }
}

// Стало
protocol PaymentGateway {
    func charge(amount: Double)
}

class PaymentProcessor {
    private let gateway: PaymentGateway
    
    init(gateway: PaymentGateway = StripeGateway()) {
        self.gateway = gateway
    }
    
    func makePayment(amount: Double) {
        gateway.charge(amount: amount)
    }
}

// Mock для тестов
class MockPaymentGateway: PaymentGateway {
    var lastChargedAmount: Double?
    
    func charge(amount: Double) {
        lastChargedAmount = amount
    }
}

Итог

Использование простых экземпляров нарушает принцип единственной ответственности и затрудняет тестирование. Применение Dependency Injection, протоколов и моков позволяет:

• Писать изолированные юнит-тесты
• Ускорять выполнение тестов (без реальных сетевых вызовов или операций I/O)
• Упрощать рефакторинг и поддержку кода
• Повышать переиспользуемость компонентов

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