如何避免使用#ifdef提升代码可测试性？日志开关替代方案问询

Great question—preprocessor macros work for basic on/off toggling, but they’re inflexible when it comes to testing and runtime adjustments. Here are a few better approaches that boost testability while keeping the log toggle functionality:

1. Runtime Toggle with a Class-Level Flag #

This approach lets you enable/disable logs on the fly without recompiling, which is perfect for testing different scenarios (e.g., verifying logs are emitted when enabled, or checking performance when logs are off).

#include <iostream>
#include <string>

class Logger {
private:
    static bool s_loggingEnabled;
public:
    // Static methods to control logging state
    static void enable() { s_loggingEnabled = true; }
    static void disable() { s_loggingEnabled = false; }
    
    static void log(const std::string& category, const std::string& message) {
        if (s_loggingEnabled) {
            // Replace with your actual file-writing logic
            std::cout << "[LOG] " << category << ": " << message << "\n";
        }
    }
};

// Initialize the flag (default to enabled)
bool Logger::s_loggingEnabled = true;

// Example usage
int main() {
    Logger::log("Startup", "Application initialized");
    
    // Toggle logs off for a critical section
    Logger::disable();
    Logger::log("Debug", "This message won't appear");
    
    Logger::enable();
    Logger::log("Shutdown", "Application exiting");
    return 0;
}

Testability win: In unit tests, you can toggle logs mid-test to verify behavior—no need to recompile separate test builds. You can even add methods to capture log output for validation if needed.

2. Dependency Injection with a Logger Interface #

This is the gold standard for testability, as it completely decouples your business code from logging implementation. You can swap in mock loggers during tests to verify exactly what logs are emitted.

#include <iostream>
#include <string>
#include <vector>
#include <memory>
#include <cassert>

// Abstract logger interface
class ILogger {
public:
    virtual ~ILogger() = default;
    virtual void log(const std::string& category, const std::string& message) = 0;
};

// Concrete file logger (your production implementation)
class FileLogger : public ILogger {
public:
    void log(const std::string& category, const std::string& message) override {
        // Write to file logic here
        std::cout << "[FILE LOG] " << category << ": " << message << "\n";
    }
};

// Null logger (disables logs entirely)
class NullLogger : public ILogger {
public:
    void log(const std::string& category, const std::string& message) override {
        // Do nothing
    }
};

// Mock logger (for testing—captures logs to verify)
class MockLogger : public ILogger {
public:
    std::vector<std::pair<std::string, std::string>> capturedLogs;
    
    void log(const std::string& category, const std::string& message) override {
        capturedLogs.emplace_back(category, message);
    }
    
    bool hasLog(const std::string& category, const std::string& message) {
        return std::find(capturedLogs.begin(), capturedLogs.end(),
                         std::make_pair(category, message)) != capturedLogs.end();
    }
};

// Example business class that depends on logging
class DataProcessor {
private:
    std::unique_ptr<ILogger> m_logger;
public:
    // Inject logger via constructor
    DataProcessor(std::unique_ptr<ILogger> logger) : m_logger(std::move(logger)) {}
    
    void processData(const std::string& data) {
        m_logger->log("Processing", "Received data: " + data);
        // ... business logic ...
    }
};

// Test example
int main() {
    // Verify logs are emitted correctly
    auto mockLogger = std::make_unique<MockLogger>();
    DataProcessor processor(std::move(mockLogger));
    
    processor.processData("user_123");
    
    auto* mock = dynamic_cast<MockLogger*>(processor.m_logger.get());
    assert(mock->hasLog("Processing", "Received data: user_123"));
    
    // Test with logs disabled
    auto nullLogger = std::make_unique<NullLogger>();
    DataProcessor processorNoLogs(std::move(nullLogger));
    processorNoLogs.processData("user_456"); // No logs written
    
    return 0;
}

Testability win: You can validate that your code emits the exact logs you expect without relying on file system checks. You also avoid tight coupling between business logic and logging infrastructure.

3. Improved Compile-Time Toggle (If You Must Keep Macros) #

If you still want compile-time control but want to avoid the pitfalls of empty macro expansions (like broken syntax in if (LOG(...))), wrap the macro around a function instead:

#include <iostream>
#include <string>

#ifdef LOG_ENABLED
void log_impl(const std::string& category, const std::string& message) {
    // Production logging logic
    std::cout << "[LOG] " << category << ": " << message << "\n";
}
#else
void log_impl(const std::string& category, const std::string& message) {
    // Empty implementation—still a valid function call
}
#endif

#define LOG(category, message) log_impl(category, message)

// Usage
int main() {
    LOG("Test", "This works whether logs are enabled or not");
    return 0;
}

Testability win: Even with logs disabled, the macro calls a valid function, so you don’t get unexpected syntax errors. For tests, you can define LOG_ENABLED and provide a mock log_impl to capture output.

内容的提问来源于stack exchange，提问作者devdy