Использовал ли паттерн Singleton в контексте тестирования?

Да, сталкивался с Singleton в коде приложений, которые приходилось тестировать, и понимаю связанные с этим вызовы для QA.

С точки зрения тестировщика:

• Проблема для модульного тестирования: Класс-одиночка хранит глобальное состояние, что нарушает изоляцию тестов. Изменение состояния в одном тесте может привести к падению следующих.
• Стратегии обхода в тестах:
  1. Использование Dependency Injection (DI): Самый чистый способ. Если код получает экземпляр Singleton через интерфейс, в тестах его можно подменить mock-объектом.
  2. Сброс состояния: Иногда добавляют метод resetInstance() (только для тестов!), чтобы очищать состояние между тестами.
  3. Рефлексия: Использование механизмов рефлексии, чтобы обнулить приватное статическое поле, хранящее экземпляр. Это хак, но иногда применяется.

Пример проблемы и подхода с DI: Допустим, есть Logger.getInstance(). Вместо прямого вызова в коде:

// Плохо для тестирования
Logger.getInstance().log("Message");

Лучше внедрять зависимость:

// Хорошо
class Service {
    private ILogger logger; // Интерфейс
    public Service(ILogger logger) { this.logger = logger; }
    public void doWork() { logger.log("Message"); }
}

Тогда в юнит-тесте можно использовать заглушку:

@Test
public void testServiceDoWork() {
    ILogger mockLogger = Mockito.mock(ILogger.class);
    Service service = new Service(mockLogger);
    service.doWork();
    Mockito.verify(mockLogger).log("Message"); // Проверка взаимодействия
}

Таким образом, основная задача QA при работе с Singleton — обеспечить тестируемость кода, который от него зависит, часто выступая за рефакторинг в сторону внедрения зависимостей.