Как протестировать класс, который зависит от singleton?

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

Основной подход: Рефакторинг и Dependency Injection

Лучшее решение — изменить дизайн класса, чтобы он не зависел от синглтона напрямую. Вместо этого зависимость (интерфейс или абстракция, которую предоставляет синглтон) следует внедрять извне.

// Проблемный код
class OrderProcessor {
    public void Process(Order order) {
        var logger = Logger.Instance; // Прямой доступ к синглтону
        logger.Log("Processing order...");
        // ... логика
    }
}

// Рефакторинг: Внедрение зависимости
class OrderProcessor {
    private readonly ILogger _logger;
    
    // Зависимость передаётся через конструктор
    public OrderProcessor(ILogger logger) {
        _logger = logger;
    }
    
    public void Process(Order order) {
        _logger.Log("Processing order...");
        // ... логика
    }
}

В продакшене вы передадите реальный синглтон (например, new OrderProcessor(Logger.Instance)), а в тесте — заглушку.

Альтернативы, если рефакторинг невозможен

• Сброс состояния: Добавьте в синглтон метод Reset() для очистки внутреннего состояния и вызывайте его в [SetUp] или [TearDown] вашего тестового фреймворка.
• Подмена через Reflection: Используйте рефлексию, чтобы заменить приватное статическое поле экземпляра в синглтоне на mock-объект перед тестом.
• Инструменты фреймворков: Некоторые фреймворки вроде Microsoft Fakes или PowerMock позволяют подменять статические методы и синглтоны.

Вывод: Для создания надёжных и поддерживаемых тестов предпочтительнее рефакторить код, устраняя скрытую зависимость от синглтона через внедрение зависимостей. Это делает код более гибким и тестируемым. Крайние меры вроде сброса состояния стоит использовать только для легаси-кода, который нельзя изменить.