Закрытый метод поблочного тестирования в ресурсе руководящий класс (C++)

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

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

Другая возможность состоит в том, что у Foo, по-видимому, есть ряд не связанных между собой обязанностей, и, возможно, он подлежит рефакторингу. Вполне возможно, что вычисление контрольной суммы вообще не должно быть частью 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 (это для example всегда возвращал известную предопределенную контрольную сумму).

Теперь, хотя 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 . Тогда «простой» способ продолжить - создать чистый виртуальный интерфейсный класс , файл , а затем реализацию интерфейса. Тогда класс Foo будет использовать интерфейсный класс File. Например,

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

Тестирование затем выполняется путем простого создания простого подкласса для файла и его внедрения (заглушка). Также можно создать фиктивный класс (см., Например, 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 . Хотя на самом деле это не синглтон и, следовательно, все еще можно тестировать, это не изящное решение. Думаю, сейчас лучший вариант - передать хендлера.