Частный метод модульного тестирования в классе управления ресурсами (C++)

Одним из способов было бы извлечь метод контрольной суммы в его собственный класс и иметь открытый интерфейс, с которым можно было бы протестировать.

Простой и прямой ответ состоит в том, чтобы сделать ваш класс юнит-тестов другом тестируемого класса. Таким образом, класс модульного теста может получить доступ к calculateChecksum(), даже если он является частным.

Еще одна возможность, на которую следует обратить внимание, заключается в том, что Фу, по-видимому, имеет ряд несвязанных обязанностей и, возможно, должен быть рефакторизован. Вполне возможно, вычисление чековой суммы вообще не должно быть частью Foo. Вместо этого вычисление контрольной суммы может быть лучше как алгоритм общего назначения, который может любой человек применяйте по мере необходимости (или, возможно, наоборот-функтор для использования с другим алгоритмом, например std::accumulate).

Я бы начал с извлечения кода вычисления контрольной суммы в его собственный класс:

class CheckSumCalculator {
    std::wstring fileName_;

public:
    CheckSumCalculator(const std::wstring& fileName) : fileName_(fileName)
    {
    };

    int doCalculation()
    {
        // Complex logic to calculate a checksum
    }
};

Это позволяет очень легко проверить расчет контрольной суммы в изоляции. Однако вы можете сделать еще один шаг вперед и создать простой интерфейс:

class FileCalculator {

public:
    virtual int doCalculation() =0;
};

И реализация:

class CheckSumCalculator : public FileCalculator {
    std::wstring fileName_;

public:
    CheckSumCalculator(const std::wstring& fileName) : fileName_(fileName)
    {
    };

    virtual int doCalculation()
    {
        // Complex logic to calculate a checksum
    }
};

, а затем передайте интерфейс FileCalculator своему конструктору Foo:

class Foo {
    std::wstring fileName_;
    FileCalculator& fileCalc_;
public:
    Foo(const std::wstring& fileName, FileCalculator& fileCalc) : 
        fileName_(fileName), 
        fileCalc_(fileCalc)
    {
        //Construct a Foo here.
    };

    int getChecksum()
    {
        //Open the file and read some part of it

        return fileCalc_.doCalculation( something );
    }

    void modifyThisFileSomehow()
    {
        //Perform modification

        int newChecksum = fileCalc_.doCalculation( something );

        //Apply the newChecksum to the file
    }
};

В реальном производственном коде вы создадите CheckSumCalculator и передадите его в Foo, но в коде модульного теста вы можете создать Fake_CheckSumCalculator (который, например, всегда возвращает известную предопределенную контрольную сумму).

Теперь, несмотря на то, что Foo имеет зависимость от CheckSumCalculator, Вы можете построить и протестировать эти два класса в полной изоляции.

#ifdef TEST
#define private public
#endif

// access whatever you'd like to test here

Ну, предпочтительным способом в C++ для ввода-вывода файлов является поток. Поэтому в приведенном выше примере было бы гораздо более разумно, возможно, ввести поток вместо имени файла. Например,

Foo(const std::stream& file) : file_(file)

Таким образом, вы можете использовать std::stringstream для модульного тестирования и иметь полный контроль над тестом.

Если вы не хотите использовать потоки, то можно использовать стандартный пример шаблона RAII, определяющего класс File. Тогда "простой" способ - создать чистый класс виртуального интерфейса File и затем-реализация интерфейса. Затем класс Foo будет использовать файл класса интерфейса. Например,

Foo(const File& file) : file_(file)

Тестирование затем выполняется путем простого создания простого подкласса к File и введения его вместо этого (stubbing). Можно также создать макет класса (например, Google Mock).

Тем не менее, вы, вероятно, хотите также провести модульный тест класса реализации File, и поскольку это RAII, он, в свою очередь, нуждается в некоторой инъекции зависимостей. Я обычно стараюсь создать чистый класс виртуального интерфейса, который просто обеспечивает основные операции c файлами (открытие, закрытие, чтение, запись и т. д. или fopen, fclose, fwrite, fread и т. д.). Например,

class FileHandler {
public:
    virtual ~FileHandler() {}
    virtual int open(const char* filename, int flags) = 0;
    // ... and all the rest
};

class FileHandlerImpl : public FileHandlerImpl {
public:
    virtual int open(const char* filename, int flags) {
        return ::open(filename, flags);
    }
    // ... and all the rest in exactly the same maner
};

Этот FileHandlerImpl класс настолько прост, что я его не тестирую. Однако преимущество заключается в том, что, используя его в конструкторе класса FileImpl, я могу легко модульно протестировать класс FileImpl. Например,

FileImple(const FileHandler& fileHandler, const std::string& fileName) : 
    mFileHandler(fileHandler), mFileName(fileName)

Единственным недостатком до сих пор является то, что FileHandler приходится передавать по кругу. Я подумал об использовании интерфейса FileHandle фактически предоставить статический экземпляр set / get-методы, которые можно использовать для получения одного глобального экземпляра объекта FileHandler. Хотя на самом деле он не является синглетным и поэтому все еще поддается модульному тестированию, это не элегантное решение. Я думаю, что передача обработчика - это лучший вариант прямо сейчас.