Как организовать организацию модульного тестирования для унаследованного кода Visual C ++?

Question

У меня есть проект Visual Studio 2005 C ++, это консольное приложение.

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

Я не хочу, чтобы большая часть моего тестового кода заканчивалась обычным .exe в рабочей среде, поэтому я подумал, что лучше будет создать отдельный проект для моих тестов. Первая проблема, как этот новый проект будет вызывать остальную часть кода? Должен ли я сделать свой прежний код .lib или .dll с одной точкой входа и создать отдельный проект, который вызывает основную часть моего прежнего кода?

Должен ли я пойти на уродливый взлом, поместив все мои тесты в файлы, которые полностью #ifdef TESTING, чтобы код не попал в мой производственный .exe? Если это так, как я должен условно загрузить мою среду тестирования? Использовать отдельную конфигурацию свойств для тестирования?

Я в основном ищу любые предложения о том, как получить тестовый набор для устаревшего .exe-проекта в Visual C ++

Answer 1

Во-первых, я настоятельно рекомендую книгу Майкла Фезера "Эффективная работа с устаревшим кодом" . Это все о том, как добавить автоматизированные модульные тесты в устаревшее приложение, которое не имеет тестов. Если вам интересно, «как мне вообще начать тестировать эту кучу кода», тогда эта книга для вас.

Майкл также является автором CppUnit, NUnit-подобной среды тестирования с открытым исходным кодом для кода C ++. Вы можете найти его здесь: http://sourceforge.net/projects/cppunit/.

Один из простых и быстрых способов добавления тестов - добавить конфигурацию UnitTest в ваше решение. Эта конфигурация скомпилирует ваш код, но вместо того, чтобы связать его с вашим main.CPP, вы исключите ваш main.cpp из сборки и включите UnitTestMain.cpp, где вы будете размещать вызовы для выполнения модульных тестов. Мы начали так давно, когда не знали ничего лучшего. Тем не менее, вы тратите много времени, включая и исключая все различные модули testMyCode.cpp для различных конфигураций, и через некоторое время это утомляет. Мы обнаружили, что разработчикам такой подход не очень понравился.

Гораздо лучший подход - добавить проект модульного тестирования в ваше решение с зависимостью сборки от вашего реального проекта. Если проект называется Foo.vcproj, назовите его Foo_test.vcproj. Этот проект содержит только ваш тестовый код, он включает в себя ваши заголовки Foo и ссылки на ваши скомпилированные модули fooCode.obj. Добавьте вызов для выполнения Foo_test.exe в качестве шага после сборки сборки Foo_test, и он автоматически запускает модульные тесты во время сборки. Если какой-либо модульный тест не пройден, сборка завершится неудачно. Если на вашем сервере сборки настроены проверки с использованием gated, никто не сможет проверить изменения, которые нарушают существующие тесты.

Answer 2

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

Одно из решений состоит в том, чтобы иметь отдельную конфигурацию проекта (например, Debug, Release и Test) и иметь свой тестовый код в отдельных файлах, помеченных как «Исключенные из сборки» в конфигурациях Debug и Release. Вы можете иметь простой код для запуска тестов в #ifdef или иметь версию-заглушку для запуска тестов, включенную в не-тестовые сборки.

Другой вариант (хотя это скорее хакерский код) - запустить тестовый код с WinMain, а рабочий код - с обычного старого main. При сборке с использованием подсистемы «Windows» будут выполняться ваши тесты, а при сборке для подсистемы Console будет запущен производственный код. Однако я не знаю, будет ли компоновщик отбрасывать непроверенные тестовые функции из производственной сборки.