Я предполагаю, что это домашнее задание, так что вы, вероятно, хотите перейти сюда . Он содержит учебник, объясняющий связанные списки, дает хороший псевдокод, а также имеет реализацию C ++, которую вы можете скачать.
Я бы рекомендовал прочитать объяснение и понять псевдокод, прежде чем вслепую использовать реализацию. Это тема, которую вы действительно должны глубоко понять, если хотите продолжить в CS.
BOOST.Test очень гибкий, и вы, вероятно, можете делать то, что хотите. Однако, поскольку вы говорите, что вы новичок в модульном тестировании, вам, вероятно, следует придерживаться стандартной структуры модульного тестирования.
Это должен быть отдельный тестовый проект для каждого проекта, который вы тестируете. Затем включите источники и библиотеки, необходимые для создания тестового проекта.
Это проще, поскольку в вашем основном проекте нет логики тестирования, которая могла бы запускаться случайно, и тесты легко запускать, поскольку у них есть собственный исполняемый файл. Этот подход также работает для библиотек тестирования. Если вы будете следовать этой структуре, то обнаружите, что большинство значений по умолчанию для BOOST.Test работают из коробки, и вы можете просто беспокоиться о написании тестов и кода.
В вашем test_foo.cpp
макросы добавляют наборы тестов и наборы тестов в
в глобальный список: master_testsuite
, который является корнем всех тестов
узлы. Вам просто нужно скомпилировать все тестовые файлы, например
test_foo.cpp
, test_boo.cpp
и бегун, а затем свяжите их все в
Функция unit_test_main
используется для запуска тестов в master_testsuite
.
boost::unit_test::unit_test_main(
&init_unit_test,
argc,
argv
)
На основе макроса, который вы определили перед включением
, Boost.Test может уже генерировать main
функция для вас. [1] Сгенерированный main
просто вызвал
unit_test_main
с argc
и argv
в main
. Рекомендуется
используйте unit_test_main
, потому что он может обрабатывать некоторые аргументы консоли,
например запустить тест по имени .
Первым аргументом unit_test_main
является ловушка. В зависимости от
BOOST_TEST_ALTERNATIVE_INIT_API
, у него другое определение.
#ifdef BOOST_TEST_ALTERNATIVE_INIT_API
typedef bool (*init_unit_test_func)();
#else
typedef test_suite* (*init_unit_test_func)( int, char* [] );
#endif
Вы можете настроить master_testsuite
в ловушке. Во-вторых
форме, возвращаемое значение - новый главный набор тестов.
[1] если определены BOOST_TEST_MAIN
и BOOST_TEST_MAIN
, но
BOOST_TEST_NO_MAIN
- нет.
Вы можете запустить тесты, например, из команды меню, но это не так просто и, к сожалению, плохо документировано. Еще печальнее - невозможно указать путь, по которому должен быть создан файл журнала. Мне пришлось самому добавить такую опцию командной строки. К сожалению, я еще не отправил его. Мой код выглядит так:
#ifdef DEBUG
#undef main
#define BOOST_TEST_MAIN
#include <boost/test/included/unit_test.hpp>
int DoUnitTests()
{
char *args[] = {"", "--log_level=all", "--auto_start_dbg=yes"};
bool result = ::boost::unit_test::unit_test_main(&init_unit_test_suite, sizeof(args) / sizeof(char*), args);
MessageDlog("Unittests result: %s", result ? "ERRORS in Unittests" : "Goooood!");
return result;
}
#else
int DoUnitTests()
{
}
#endif
нет автономного средства запуска тестов, как в NUnit
, вы просто создаете тестовые случаи как одно приложение .exe (если вы работаете в Windows), и вы запускаете его
Попробуйте этот сценарий, который я написал, который, учитывая имя программы а список классов сгенерирует make-файл, скелет проекта и скелеты набора тестов для каждого класса / модуля. Он также настраивает все это так, чтобы набор тестов для каждого класса можно было запускать либо индивидуально, либо как часть глобального набора «все-в-одном».
Это вызов makeSimple , он доступен на sourceforge.