Я твердо убежден в использовании модульных тестов как части построения больших многоплатформенных приложений. В настоящее время мы планируем провести наши модульные тесты в рамках отдельного проекта. Это помогает сохранить чистую базу кода. Я думаю, однако, что это отделит тестовый код от реализации устройства. Что вы думаете об этом подходе и есть ли такие инструменты, как JUnit для приложений на С++?
Как вы реализуете модульное тестирование в крупных проектах на С++?
Ответ 1
Для С++ существует множество фреймворков Test Unit. CppUnit, конечно, не тот, который я бы выбрал (по крайней мере, в его стабильной версии 1.x, поскольку ему не хватает многих тестов и требует много избыточных строк кодов). Пока что моя предпочтительная структура CxxTest, и я планирую оценить Fructose.
В любом случае существует несколько "документов", которые оценивают рамки С++ TU:
Ответ 2
Это разумный подход.
У меня были очень хорошие результаты как с UnitTest ++ и Boost.Test
Я посмотрел на CppUnit, но для меня это больше походило на перевод материала JUnit, а не на С++.
Обновление: В настоящее время я предпочитаю использовать Catch. Я нашел его эффективным и простым в использовании.
Ответ 3
Вы должны разделить свой базовый код на общую (динамическую) библиотеку, а затем написать основную часть своих модульных тестов для этой библиотеки.
Два года назад (2008) я участвовал в крупном проекте LSB Infrastructure, развернутом Linux Foundation. Одной из целей этого проекта было написать модульные тесты для 40 000 функций из основных библиотек Linux. В контексте этого проекта мы создали технологию AZOV и базовый инструмент с именем API Sanity Autotest, чтобы автоматически генерировать все тесты. Вы можете попытаться использовать этот инструмент для генерации модульных тестов для вашей базовой библиотеки (ы).
Ответ 4
Я использую UnitTest ++. Тесты находятся в отдельном проекте, но фактические тесты переплетаются с фактическим кодом. Они существуют в папке под тестируемой секцией.
а именно:
MyProject\src\< - источник фактического приложения
MyProject\src\tests < - источник тестов
Если у вас есть вложенные папки (а кто нет), то у них тоже будет свой собственный \test подкаталог.
Ответ 5
Cppunit является прямым эквивалентом приложений Junit для С++ http://cppunit.sourceforge.net/cppunit-wiki
Лично я создал модульные тесты в другом проекте и создал отдельную конфигурацию сборки, которая построила все модульные тесты и зависимый исходный код. В некоторых случаях я хотел протестировать частные функции-члены класса, поэтому я сделал класс Test классом друзей для проверяемого объекта, но спрятал объявления друзей при построении в "не-тестовых" конфигурациях через объявления препроцессора.
Я закончил эту гимнастику кодирования, так как я интегрировал тесты в устаревший код. Если вы начинаете с целью модульного тестирования, лучший дизайн может быть простым.
Ответ 6
Вы можете создать проект unit test для каждой библиотеки в исходном дереве в подкаталоге этой библиотеки. В итоге вы получаете приложение для тестового драйвера для каждой библиотеки, что упрощает запуск одного набора тестов. Поместив их в подкаталог, он держит вашу базу кода чистой, но также держит тесты близко к коду.
Сценарии могут быть легко записаны для запуска всех наборов тестов в исходном дереве и сбора результатов.
Я использую индивидуальную версию оригинального CppUnit в течение многих лет с большим успехом, но есть и другие альтернативы. GoogleTest выглядит интересным.
Ответ 7
Я думаю, что вы на правильном пути с модульным тестированием, и это отличный план для повышения надежности вашего продукта.
Хотя модульное тестирование не решит все ваши проблемы при конвертировании вашего приложения на разные платформы или даже в разные операционные системы. Причиной этого является тестирование модулей процесса, чтобы выявить ошибки в вашем приложении. Он просто бросает столько входов, которые можно вообразить в вашей системе, и ждет результата на другом конце. Это похоже на то, чтобы обезьяна постоянно била по клавиатуре и наблюдала результаты (бета-тестеры).
Чтобы перейти к следующему шагу, при хорошем модульном тестировании вам необходимо сосредоточиться на своем внутреннем дизайне вашего приложения. Лучший подход, который я нашел, - использовать шаблон дизайна или процесс проектирования, называемый "контрактное программирование" или "Дизайн по контракту". Другая книга, которая очень полезна для создания надежности в вашем основном дизайне, была.
Отладка процесса разработки: практические стратегии для сосредоточения внимания, достижения дат кораблей и создания твердых команд.
В нашей команде разработчиков мы очень внимательно посмотрели на то, что мы считаем ошибкой программиста, ошибкой разработчика, ошибкой проектирования и тем, как мы можем использовать как модульное тестирование, так и надежность построения в нашем программном пакете через DBC и следуя рекомендациям отлаживая процесс разработки.
Ответ 8
CxxTest также стоит взглянуть на легкую, удобную кросс-платформу JUnit/CppUnit/xUnit-подобную структуру для С++. Нам очень легко добавлять и разрабатывать тесты
Aeryn - еще одна С++ Testing Framework, которая стоит посмотреть
Ответ 9
Использование tut http://tut-framework.sourceforge.net/ очень простой, просто заголовок не содержит макросов. Может генерировать результаты XML