До сих пор я использовал импровизированную модульную процедуру тестирования - в основном, весь пакет программ unit test запускался автоматически пакетным файлом. Хотя многие из них явно проверяют свои результаты, намного больше обманывают - они выгружают результаты в текстовые файлы, которые версируются. Любое изменение результатов теста помечено подрывной деятельностью, и я могу легко определить, что такое изменение. Многие из тестов выводят файлы точек или другую форму, которая позволяет мне получить визуальное представление вывода.
Проблема в том, что я переключаюсь на использование cmake. Переход с потоком cmake означает использование сборок вне источника, что означает, что удобство распаковки получается в общей папке источника/сборки, а их версия вместе с источником не работает.
В качестве замены, я бы хотел сказать, что инструмент unit test найдет файлы ожидаемых результатов (в исходном дереве) и попросит его выполнить сравнение. При сбое он должен предоставлять фактические результаты и списки различий.
Возможно ли это, или я должен использовать совершенно другой подход?
Очевидно, я мог бы игнорировать ctest и просто приспосабливать то, что я всегда делал, к сборке вне источника. Я мог бы, например, реализовать версию моей папки-где-все-строить-жить (с либеральным использованием "игнорировать", конечно). Это здорово? Вероятно, нет, так как каждая сборка будет иметь отдельную копию ожидаемых результатов.
Кроме того, любые советы по рекомендуемому способу проведения модульного тестирования с помощью cmake/ctest получаются графоподобно. Я потратил немного времени на cmake, но не потому, что это плохо, а потому, что я не понимал, как лучше работать с ним.
ИЗМЕНИТЬ
В конце концов, я решил как можно проще сохранить сторону cmake/ctest модуля. Чтобы проверить фактические данные по ожидаемым результатам, в моей библиотеке я нашел дом для следующей функции...
bool Check_Results (std::ostream &p_Stream ,
const char *p_Title ,
const char **p_Expected,
const std::ostringstream &p_Actual )
{
std::ostringstream l_Expected_Stream;
while (*p_Expected != 0)
{
l_Expected_Stream << (*p_Expected) << std::endl;
p_Expected++;
}
std::string l_Expected (l_Expected_Stream.str ());
std::string l_Actual (p_Actual.str ());
bool l_Pass = (l_Actual == l_Expected);
p_Stream << "Test: " << p_Title << " : ";
if (l_Pass)
{
p_Stream << "Pass" << std::endl;
}
else
{
p_Stream << "*** FAIL ***" << std::endl;
p_Stream << "===============================================================================" << std::endl;
p_Stream << "Expected Results For: " << p_Title << std::endl;
p_Stream << "-------------------------------------------------------------------------------" << std::endl;
p_Stream << l_Expected;
p_Stream << "===============================================================================" << std::endl;
p_Stream << "Actual Results For: " << p_Title << std::endl;
p_Stream << "-------------------------------------------------------------------------------" << std::endl;
p_Stream << l_Actual;
p_Stream << "===============================================================================" << std::endl;
}
return l_Pass;
}
Типичный unit test теперь выглядит примерно как...
bool Test0001 ()
{
std::ostringstream l_Actual;
const char* l_Expected [] =
{
"Some",
"Expected",
"Results",
0
};
l_Actual << "Some" << std::endl
<< "Actual" << std::endl
<< "Results" << std::endl;
return Check_Results (std::cout, "0001 - not a sane test", l_Expected, l_Actual);
}
В тех случаях, когда мне нужна повторно используемая функция демпинга данных, она принимает параметр типа std::ostream&, поэтому он может сбрасывать поток фактических результатов.
