Как выполнить юнит-тестирование методов, связанных с выводом файлов?

Question

Я использую C ++ Test от Parasoft для модульного тестирования кода C ++. Я столкнулся со следующей проблемой. У меня есть функция, похожая на следующую (псевдокод):

bool LoadFileToMem(const std::string& rStrFileName)
{
    if( openfile(rStrFileName) == successfull )
    {
         if( get_file_size() == successfull )
         {
            if( read_entire_file_to_buffer() == successfull )
            {
                return true;
            }
            return false;
         }
         return false;
    }
    return false;
}

Мои вопросы в этом случае:

Должен ли я использовать заглушки для функций файловой системы? Или я должен включить конкретные образцы тестовых файлов для запуска модульных тестов?

В моем случае класс std :: fstream используется для ввода файла.

Кто-нибудь лучше предложения? (Лучше всего, если сделано в C ++ Test, но не обязательно).

Answer 1

Я бы пошел для коротких образцов тестовых файлов. Они могут быть проверены в системе контроля версий вместе с тестовым кодом. Причина, по которой я хотел бы сделать это, состоит в том, что ваша функция состоит в том, чтобы загрузить файл, поэтому это то, что вы должны тестировать.

Answer 2

Для модульного тестирования этой функции вы должны использовать заглушки для каждой из вызываемых функций.

Каждая вызываемая функция имеет свой собственный набор тестов, который выполняет эту функцию.

Для read_entire_file_to_buffer() требуется, чтобы по крайней мере один тестовый файл, массово переполняющий буфер, проверял, что вы не аварийно завершаете работу и не записываете, когда они передают вам истории Нью-Йоркской фондовой биржи вместо 40-символьного файла конфигурации, который вы ожидали.

Answer 3

Мое предложение:

Создание заглушек для функций, которые будут вызывать эту функцию.

Создание модульного теста для этой конкретной функции с примерами тестовых файлов.

Создание интеграционного теста без заглушек для проверки всего процесса.

Answer 4

Честно говоря, я бы разделил эту функцию на две части. Одна функция будет читать из std::istream, а другая откроет файл и вернет ifstream (возможно, выделенную из кучи умным указателем). Затем вы можете легко выполнить модульное тестирование первого, указав istringstream вместо ifstream, а последнее также должно быть легко тестируемым.

Answer 5

Я думаю, что вы ищете технику под названием неисправность инъекции . Несколько лет назад я видел проект, который заставлял программы переходить в редко проверенные условия ошибок (ошибки прав доступа к файлу, malloc возвращает 0 и т. Д.) ... Я просто не могу вспомнить его название. Надеюсь, что ссылка на Википедию поможет вам начать.

Answer 6

Как правило, в модульном тестировании хорошей идеей является, чтобы вы максимально имитировали исходную функциональность, охватывая как можно большую часть тестируемого кода (покрытие кода). Помимо заглушек, с которыми я не знаком, примером может быть то, что вы хотите убедиться, что, если указано неправильное имя файла, и т.д., строка 3 в вашем файле:

if (openfile (rStrFileName) == successfull)

тогда вы точно справитесь с этой ситуацией и вернете false. Если это может быть сделано заглушками, то пусть будет так. В моем случае я бы использовал образец тестового файла и сохранил его вместе со своими тестами. Это обычная практика.

Помните, что весь смысл в том, чтобы протестировать функцию как можно ближе к реальности. Это обеспечит автоматическое обнаружение множества странных случаев, которые вы не можете предвидеть, чтобы вы могли исправить это, что является точкой начала модульного тестирования.