Фреймворк модульного тестирования C++

Попробуйте WinUnit. Звучит отлично и рекомендуется Джон Роббинс.

http://groups.google.com/group/googletestframework, но он довольно новый

Я большой поклонник UnitTest ++, он очень легкий, но выполняет свою работу. Там вы можете легко запускать одиночные тесты.

Eclipse / JUnit - надежный пакет для java, и для обоих есть расширения / эквиваленты C++. Он может делать то, о чем вы говорите. Конечно, вам придется менять IDE ...

Отличный вопрос! Несколько лет назад я вечно искал что-то стоящее, но у меня ничего не вышло. Я искал что-то очень легкое и не требовало от меня компоновки некоторых библиотек ... вы знаете что-то, что я мог бы запустить за считанные минуты.

Однако я упорствовал и в итоге наткнулся на cxxtest.

С веб-сайта:

• Не требует RTTI
• Не требует функций шаблона члена
• Не требует обработки исключений
• Не требует каких-либо внешних библиотек (включая управление памятью, файловый / консольный ввод-вывод, графические библиотеки)
• Распространяется полностью в виде набора файлов заголовков (и скрипта Python).

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

Я тоже фанат UnitTest ++.

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

Я изменил UnitTest ++, чтобы его можно было интегрировать с проектом, добавив по одному файлу .h и .cpp. Это я окрестил "милейшим". Подробности на http://ravenspoint.com/blog/index.php?entry=entry080704-063557

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

Мне нравится среда модульного тестирования Boost, главным образом потому, что она очень легкая.

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

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

Я бы предположил, что автоматическое отключение тестовых функций было бы скорее функцией (сценариев для фреймворка или) рассматриваемой среды разработки. Предположительно, приложения CodeGear C++ Builder будут быстро генерировать тестовый код для пользовательских функций.

Взгляните на Google C++ Testing Framework.

Он используется Google для всех своих собственных проектов на C++, так что, должно быть, он неплохой.

http://googletesting.blogspot.com/2008/07/announcing-new-google-c-testing.html

http://code.google.com/p/googletest

Я только что ответил на очень похожий вопрос. В итоге я использовал UnitTest ++ Ноэля Ллописа. Мне он понравился больше, чем boost :: test, потому что он не настаивал на реализации основной программы тестовой системы с помощью макроса - он может подключаться к любому исполняемому файлу, который вы создаете. Он действительно страдает от того же препятствия, что и boost :: test, поскольку требует, чтобы библиотека была подключена. Я использовал CxxTest, и он подходит ближе, чем что-либо еще в C++, для автоматической генерации тестов (хотя для этого требуется Perl быть частью вашей системы сборки для этого). C++ просто не предоставляет перехватчиков отражения, которые есть в языках .NET и Java. Инструменты MsTest в Visual Studio Team System - Developer's Edition будут автоматически генерировать тестовые заглушки неуправляемого C++, но для этого методы должны быть экспортированы из DLL, поэтому он не работает со статическими библиотеками. Другие тестовые среды в мире .NET тоже могут обладать этой способностью, но я не знаком ни с одной из них. Итак, прямо сейчас мы используем UnitTest ++ для неуправляемого C++, и в настоящее время я выбираю между MsTest и NUnit для управляемых библиотек.

Я использую Тут-фреймворк

Айрин - еще один фреймворк, на который стоит обратить внимание

Boost.Test позволяет запускать тестовый пример по имени. Или набор тестов. Или их несколько.

Boost.Test НЕ настаивает на реализации main, хотя делает это легко.

Boost.Test НЕ ОБЯЗАТЕЛЬНО использовать в качестве библиотеки. Имеет вариант с одним заголовком.

CppUnit был оригинальной данью уважения JUnit.

Я только что выпустил свой собственный фреймворк ЛОВИТЬ. Он все еще находится в разработке, но я считаю, что он уже превосходит большинство других фреймворков. У разных людей разные критерии, но я попытался охватить большую часть вопросов без особых компромиссов. Взгляните на мою связанную запись в блоге для дегустатора. Мои пять основных функций:

• Только заголовок
• Автоматическая регистрация тестов на основе функций и методов
• Разлагает стандартные выражения C++ на LHS и RHS (поэтому вам не нужно целое семейство макросов assert).
• Поддержка вложенных секций в приспособлении на основе функций
• Именные тесты с использованием естественного языка - генерируются имена функций / методов

не создает заглушки, но это довольно специализированная область. Я думаю, что Изолятор ++ - первый инструмент, который действительно справится с этим. Обратите внимание, что фреймворки Mocking / stubbing обычно не зависят от фреймворков модульного тестирования. CATCH особенно хорошо работает с фиктивными объектами, поскольку состояние теста не передается контекстом.

Он также имеет привязки Objective-C.

[Обновить]

Просто произошло это с моим ответом несколько лет назад. Спасибо за отличные комментарии! Очевидно, что Catch за это время сильно развился. Теперь он поддерживает тестирование стиля BDD (задано / когда / тогда), теги, теперь в заголовке Один, и множество внутренних улучшений и уточнений (например, более богатая командная строка, четкий и выразительный вывод и т. д.). Более свежая запись в блоге находится здесь.

Стоит проверить библиотеку фруктозы Эндрю Марлоу ... http://fructose.sourceforge.net/

Я вспоминаю его документы, содержащие довольно подробный анализ и сравнение других предложений на момент написания «Фруктозы», но не могу найти URL-адрес, непосредственно ведущий к этому документу.

Я пробую Иглу, также набор тестов C++ только для заголовков, даже если две включенные зависимости являются только заголовками.

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

Visual Studio имеет встроенную среду модульного тестирования, это отличная ссылка для настройки тестового проекта для консольного приложения win32:

http://codeketchup.blogspot.ie/2012/12/unit-test-for-unmanaged-c-in-visual.html

Если вы работаете над статическим проектом DLL, его намного проще настроить, поскольку другие отмечали, что внешние фреймворки для тестирования, такие как GTest и Boost, имеют дополнительные функции.