Как вы интегрируете TDD-подход с VisualStudio?

Мне интересно узнать о возможностях использования TDD и модульного тестирования для С++ в целом с Visual Studio 2005 (Professional)

Сначала немного фона. У нас довольно большой проект, и большая часть его была разработана в Linux с использованием CppUnit для модульных тестов. Проект разделен на несколько библиотек, каждый из которых имеет свой собственный набор тестов. У меня есть простой script, который компилирует библиотеку, компилирует тестовый набор и затем запускает тесты. Поэтому после внесения изменений в код я просто запускаю "тест" из командной строки и запускает тесты.

Теперь большинство разработчиков используют Visual Studio 2005 для Windows для разработки этого продукта. Конечно, они все равно могут запускать тесты из командной строки с использованием nmake, но требуют дополнительных шагов, и я предпочел бы иметь гораздо более интегрированное решение.

Итак, мой вопрос состоит из двух частей.

Во-первых, каков наилучший способ изложения кода для тестов на большой базе кода? Нормально ли создавать несколько тестовых проектов в решении, по одному для каждой библиотеки?

Во-вторых, есть ли какие-либо инструменты для интеграции тестов CppUnit в Visual Studio? При зависимостях, установленных при непосредственном запуске, тестовый проект должен запускать тесты, но в настоящее время результаты все еще появляются в окне команд.

Ответ 1

Один из проектов в моей компании делает именно это. Мы используем структуру unit test под названием CXXTest (http://cxxtest.sourceforge.net/guide.html). Нам очень нравится эта среда для С++, потому что требуется только написать заголовочный файл, содержащий ваши модульные тесты. Файлы .CPP создаются с помощью script (оба сценария Python и Perl предоставляются).

Интегрируем с визуальной студией, предоставляя шаг пост-сборки, который строит модульные тесты (если они нуждаются в создании), а затем выполняет их. В окне вывода отображается вывод (показывая, что прошло и что не удалось) - вам никогда не нужно покидать среду IDE.

Ответ 2

Я использую среду тестирования Boost. Я склонен разбивать свой код на .lib файлы и будет иметь отдельный тестовый проект EXE для консольного режима для каждого. Когда тестовый проект построен, он использует "стадию пост-сборки" для запуска самого себя, тем самым запуская тесты. Вы можете сделать каждый тестовый проект зависимым от вашего основного приложения, чтобы каждый раз, когда он строит, все тесты запускаются первыми, но это может занять много времени. Вместо этого я стараюсь запускать тестовые проекты вручную, но моя автоматическая система ночной сборки будет запускать все тестовые проекты, как само собой разумеющееся (I script, и если какие-либо тесты не удались, сборка завершилась неудачно, и я получаю уведомление по электронной почте).

Подробнее здесь.

Ответ 3

Я нахожу следующую иерархию папок полезной. Создайте код и тесты как подпапки ProjectFolder. Создайте 2 решения:\Project.sln и tests\Tests.sln. Теперь для каждой библиотеки классов или исполняемого файла, например, У Customers.dll есть соответствующая тестовая dll. Таким образом, код \Customers\Customers.csproj будет иметь тесты \Customers\TestCustomers.csproj, который ссылается на первый.
Интеграция CPPUnit в Visual Studio будет в порядке выбора правильного приложения в свойствах проекта. Настройки "Отладка". Я думаю, эта страница имеет то, что вам нужно, чтобы выполнить однократное нажатие тестового теста + сообщение в среде IDE.

Ответ 4

Вот что я делаю:

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

Лично я не думаю, что тестовая среда (тест Google, тест Boost, CppUnit и т.д.) имеет большое значение. Большинство из них практически функционально эквивалентны.

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

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

Ответ 5

Моя команда в настоящее время использует систему, в которой у нас есть автоматическая ночная сборка (которая также может запускаться из панели управления проектами кем угодно), которая включает в себя VS2k5 "тестовое" решение. В тестовом решении хранятся все проекты unit test; один проект unit test для каждой "единицы" кода в основном проекте.

Когда выполняется автоматическая сборка, он создает основное решение, затем тестовое решение и, наконец, запускает все исполняемые файлы, созданные тестовым решением (Perl script склеивает это вместе). Результаты компиляции, а также выполнения теста (EXIT _ SUCCESS, EXIT _ FAILURE) используются для обновления панели мониторинга проекта.

Этот трюк EXIT _ FAILURE также может быть применен к шагу пользовательской сборки основного проекта: если шаг пользовательской сборки unit test возвращает EXIT _ FAILURE, то сама сборка не выполняется.

Ответ 6

Вы также можете использовать управляемый С++ для написания модульных тестов в Visual Studio с использованием встроенной модульной системы тестирования.

Ответ 7

Посмотрите CUnitWin32. Там также был пример.