В чем проблема при тестировании Singleton?

Проблемы тестирования Singleton паттерна

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

Основная проблема: Глобальное состояние

class Database {
private:
    static Database* instance;
    Database() {}  // Приватный конструктор

public:
    static Database& getInstance() {
        if (!instance) {
            instance = new Database();
        }
        return *instance;
    }
    
    void execute(const std::string& query) { /* ... */ }
};

Database* Database::instance = nullptr;

Проблема 1: Состояние переносится между тестами

TEST(DatabaseTests, FirstTest) {
    Database& db = Database::getInstance();
    db.execute("INSERT INTO users VALUES (Alice)");
    // После теста база остаётся с пользователем Alice
}

TEST(DatabaseTests, SecondTest) {
    Database& db = Database::getInstance();  // SAME INSTANCE!
    auto users = db.getAllUsers();
    ASSERT_EQ(users.size(), 1);  // Alice всё ещё здесь!
    // Тест зависит от порядка выполнения и предыдущих тестов
}

Проблема 2: Невозможно создать mock/заглушку

// Класс, который использует Singleton
class UserService {
public:
    void createUser(const std::string& name) {
        Database& db = Database::getInstance();  // ЖЁСТКО ПРИВЯЗАНО!
        db.execute("INSERT INTO users VALUES (\"" + name + "\")");
    }
};

// Тестирование:
TEST(UserServiceTests, CreateUserTest) {
    UserService service;
    
    // Хотим подменить Database на mock, но не можем!
    // getInstance() всегда вернёт реальный Singleton
    MockDatabase mock;  // Создаём mock, но он не используется
    
    service.createUser("Bob");  // Пишет в РЕАЛЬНУЮ БД!
    // Тестируем с побочными эффектами, медленно, опасно
}

Проблема 3: Нет способа переинициализировать Singleton

TEST(DatabaseTests, ConnectionTest) {
    Database& db1 = Database::getInstance();
    // ... сконфигурировали для первого теста ...
}

TEST(DatabaseTests, AnotherConnectionTest) {
    Database& db2 = Database::getInstance();  // ОДИН И ТОТ ЖЕ ЭКЗЕМПЛЯР!
    // Конфиг из предыдущего теста всё ещё там
    // Нет способа "перезагрузить" Singleton
}

Проблема 4: Многопоточность и race conditions

class ThreadUnsafeSingleton {
private:
    static ThreadUnsafeSingleton* instance;

public:
    static ThreadUnsafeSingleton& getInstance() {
        if (!instance) {  // ЧЕК БЕЗ БЛОКИРОВКИ!
            // Thread 1 проходит проверку
            // Thread 2 проходит проверку
            // ОБА СОЗДАЮТ ЭКЗЕМПЛЯР!
            instance = new ThreadUnsafeSingleton();
        }
        return *instance;
    }
};

При тестировании:

TEST(ThreadSafetyTests, RaceCondition) {
    std::vector<std::thread> threads;
    
    for (int i = 0; i < 100; ++i) {
        threads.emplace_back([] {
            auto& s = ThreadUnsafeSingleton::getInstance();
            // Может быть несколько экземпляров!
            // Тест нестабилен, падает случайно
        });
    }
    
    for (auto& t : threads) t.join();
}

Проблема 5: Сложность проверки побочных эффектов

class Logger : public Singleton {
public:
    void log(const std::string& message) {
        // Пишет в файл на диск
        // Пишет в syslog
        // Пишет в сеть
    }
};

class ServiceUnderTest {
public:
    void doSomething() {
        Logger::getInstance().log("Starting");  // Глобальный побочный эффект!
        // Реальное логирование происходит
        Logger::getInstance().log("Done");
    }
};

TEST(ServiceTests, FunctionTest) {
    ServiceUnderTest service;
    service.doSomething();
    // Как проверить, что логи записались правильно?
    // Нужно читать файл с диска или проверять syslog
    // Медленно, ненадёжно, зависит от окружения
}

Решение 1: Инъекция зависимостей (Dependency Injection)

// Избегаем Singleton, передаём зависимость явно
class Database { /* ... */ };

class UserService {
private:
    Database& db;  // Зависимость

public:
    UserService(Database& database) : db(database) {}  // Конструктор инъекции
    
    void createUser(const std::string& name) {
        db.execute("INSERT INTO users VALUES (\"" + name + "\")");  // Используем переданную БД
    }
};

TEST(UserServiceTests, CreateUserTest) {
    MockDatabase mock;  // Создаём mock
    UserService service(mock);  // Передаём mock вместо реальной БД
    
    service.createUser("Bob");
    ASSERT_TRUE(mock.executeWasCalled());  // Проверяем, что mock был вызван
    // Быстро, надёжно, без побочных эффектов
}

Решение 2: Сеттер для переопределения Singleton

class Database {
private:
    static Database* instance;
    static bool use_real_instance;
    Database() {}

public:
    static Database& getInstance() {
        if (!instance) {
            instance = new Database();
        }
        return *instance;
    }
    
    // ТОЛЬКО ДЛЯ ТЕСТОВ!
    static void setInstance(Database* test_instance) {
        instance = test_instance;
    }
    
    static void resetInstance() {
        if (instance) {
            delete instance;
            instance = nullptr;
        }
    }
};

TEST(DatabaseTests, TestWithMock) {
    MockDatabase mock;
    Database::setInstance(&mock);
    
    // Используем mock
    Database& db = Database::getInstance();
    ASSERT_TRUE(dynamic_cast<MockDatabase*>(&db));
    
    // Восстанавливаем
    Database::resetInstance();
}

Решение 3: Thread-local storage для тестов

class Database {
private:
    static thread_local Database* instance;

public:
    static Database& getInstance() {
        if (!instance) {
            instance = new Database();
        }
        return *instance;
    }
    
    // Для тестов
    static void setTestInstance(Database* test_instance) {
        instance = test_instance;  // Только для текущего потока
    }
};

TEST(ThreadLocalTests, IsolatedInstances) {
    MockDatabase mock;
    Database::setTestInstance(&mock);
    
    // В этом потоке используется mock
    // Другие потоки не затронуты
}

Решение 4: Factory паттерн вместо Singleton

// Вместо Singleton
class DatabaseFactory {
private:
    static DatabaseFactory* instance;
    std::unique_ptr<Database> db;
    DatabaseFactory() {}

public:
    static DatabaseFactory& getInstance() {
        if (!instance) {
            instance = new DatabaseFactory();
        }
        return *instance;
    }
    
    Database& getDatabase() {
        if (!db) {
            db = std::make_unique<Database>();
        }
        return *db;
    }
    
    // ДЛЯ ТЕСТОВ: переопределить БД
    void setDatabase(std::unique_ptr<Database> test_db) {
        db = std::move(test_db);
    }
    
    void reset() {
        db.reset();
    }
};

TEST(FactoryTests, WithMockDatabase) {
    auto mock = std::make_unique<MockDatabase>();
    DatabaseFactory::getInstance().setDatabase(std::move(mock));
    
    // Используем, потом очищаем
    DatabaseFactory::getInstance().reset();
}

Best Practices тестирования Singleton

1. Избегай Singleton — используй DI (Dependency Injection) вместо этого
2. Если всё же Singleton — добавь методы для тестов (setInstance, reset)
3. Используй RAII для очистки — гарантируй сброс после каждого теста
4. Изолируй тесты — каждый тест должен быть независимым
5. Используй factory — для большей гибкости

// RAII guard для автоматической очистки
class SingletonGuard {
private:
    Database* original_instance;

public:
    SingletonGuard(Database* mock) : original_instance(Database::getInstance().data) {
        Database::setInstance(mock);
    }
    
    ~SingletonGuard() {
        Database::setInstance(original_instance);
    }
};

TEST(SafeTest, WithGuard) {
    MockDatabase mock;
    SingletonGuard guard(&mock);
    
    // Используем mock
    // При выходе из области видимости guard очищает Singleton
}

Резюме проблем

✗ Глобальное состояние переносится между тестами
✗ Невозможно использовать mock
✗ Нет способа переинициализировать
✗ Race conditions при многопоточности
✗ Сложно проверить побочные эффекты
✗ Низкая производительность тестов (реальные I/O)
✗ Зависимость от окружения

Вывод: Singleton усложняет тестирование. Лучше использовать Dependency Injection и передавать зависимости явно через конструктор или метод. Это делает код более тестируемым, гибким и поддерживаемым.