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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Создайте тест интеграции без заглушек, чтобы протестировать весь процесс.

Answer 4

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

if (openfile (rStrFileName) == successl)

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

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

Answer 5

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

Answer 6

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