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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

Посмотрите на CUnitWin32 . Также есть пример.