Поиск предложений по модульному тестированию приложения C ++ на несколько библиотек - PullRequest
Новая
       24

Поиск предложений по модульному тестированию приложения C ++ на несколько библиотек

1 голос
/ 28 марта 2009

Новое в модульном тестировании и приложение, которое распределено по нескольким библиотекам. Каковы некоторые предложения для модульного тестирования приложения? Если я помещу модульные тесты в их собственный проект, я могу протестировать только опубликованный интерфейс для каждой библиотеки DLL. Это то, что делает большинство людей? Или я должен положить модульные тесты с кодом в DLL и проверить там? Как лучше всего координировать все тесты в этой точке?

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

Спасибо.

Обновление:

Я думаю, чтобы уточнить, у меня есть класс A и класс B в DLL. Класс B используется классом A, но выставлен только класс A. Я хочу получить модульные тесты перед рефакторингом этого существующего кода. Таким образом, вопрос заключается в том, следует ли помещать модульные тесты с использованием кода dll для непосредственного тестирования класса A и класса B и / или проводить модульные тесты в отдельном проекте и тестировать класс A и класс B через открытый класс A?

Ответы [ 5 ]

2 голосов
/ 28 марта 2009

Мой домашний подход состоит в том, чтобы построить две разные цели:

  • сама DLL
  • Исполняемый файл теста

База кода такая же, за исключением main.cpp, который будет содержать основную библиотеку DLL для библиотеки DLL и стандартный C / C ++ int main () для исполняемого файла теста Все модульные тесты соответствуют действительному коду, управляемому препроцессором #define: 

#ifdef TESTING
tests here    
#endif

Функция main () для исполняемого файла вызывает все тесты через систему регистрации.

Большую часть времени я работаю с исполняемой версией с определенным ИСПЫТАНИЕМ. Когда я хочу собрать DLL, я переключаю цели и отменяю TESTING.

0 голосов
/ 01 апреля 2009

Я использую boost.test для проверки моих dll и исполняемых файлов. Я создаю отдельный модульный тестовый проект / исполняемый файл для каждой DLL и EXE для тестирования. Поскольку я тестирую внутренние компоненты dll, я не связываю их с тестовым проектом, но включаю источник, который хочу протестировать, непосредственно в проект. Наконец, автоматизированная сборка запускает все проекты модульного тестирования.

Мы используем CMake для создания наших проектов, и в нем есть приятный компонент CTest, который связывает все наши тесты для нас и запускает их как группу.

0 голосов
/ 29 марта 2009

Модульное тестирование в C ++ означает скорее классовое тестирование. Тестирование DLL было бы скорее интеграционным тестированием. И то, и другое необходимо, но лучше тестировать вещи на как можно более низком уровне. Взгляните на V-модель: http://en.wikipedia.org/wiki/V-Model_(software_development).

0 голосов
/ 29 марта 2009

В общем, тщательного тестирования общедоступного интерфейса библиотеки DLL должно быть достаточно, и, как указал Пит, действительно следует использовать все пути кода.

Что касается ответа Нейла, выбор тестовой среды, которая не требует от вас создания EXE-файлов, а напрямую работает с DLL-файлами, может еще больше упростить ситуацию. Будучи автором cfix, я, естественно, рекомендую попробовать cfix: http://www.cfix -testing.org /

0 голосов
/ 28 марта 2009

Если я помещу модульные тесты в их собственный проект, я могу проверить только опубликованный интерфейс для каждой библиотеки DLL.

В отличие от функций в DLL, к которым клиентский код не может получить доступ?

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

...