Поблочное тестирование исполняемый проект
Возможно, я не думаю об этом правильно. Я запускаю свой второй проект с помощью модульных тестов. Мой первый проект я прокрутил свое собственное для этого проекта, я испытываю Повышение:: тест.
Мой вопрос, каковы надлежащие процедуры проектов поблочного тестирования та компиляция в исполняемые файлы? На все кажется, что я вижу, там для библиотек и зависимостей. Я хочу свой exe проект быть протестированной единицей, но я не хочу набор функций модульного теста, плавающих вокруг в двоичном файле, и при этом я не хочу делать
#ifdef _DEBUG
BOOST_AUTO_TEST_CASE( my_func )
{
}
#endif
вокруг всех моих тестов.
Я думал о создании отдельного проекта для модульных тестов, но это действительно не работает на исполняемый файл.. если я не хочу сделать, некоторое воображение предварительно создает операционное копирование с моего другого проекта в тестовый проект..
Какие-либо мысли или идеи?
4 ответа
Проект может быть скомпилирован как библиотека, и эта библиотека связана, возможно, статически, в двух отдельных исполняемых файлах: «проект», который будет доставлен, и модульные тесты.
Теперь проблема, кажется, исходит из вашей IDE, какая это? Можно ли создать два бинарных файла для одного проекта?
Я использую cppunit для тестирования моих исполняемых файлов в дополнительном проекте, который просто ссылается на файлы * .obj, сгенерированные из исполняемого кода. Таким образом, у вас нет никакой тестовой логики в исходной кодовой базе, и вы можете написать отдельную консоль или приложение Windows для своих тестов.
Ура Хольгер
Модульное тестирование и исполняемый файл может быть отличной идеей, но поймите, что это совсем другой монстр, чем код модульного тестирования. Если у вас есть исполняемый файл, больше не будет C ++ или Boost. Это просто программа. У вас должна быть возможность запускать его и анализировать / контролировать ваши входные данные в другом механизме:
Вход:
- аргументы
stdin- переменные среды (возможно)
- файлы конфигурации (возможно)
Вывод:
- возвращаемое значение
stdout- файлы вывода (возможно)
Вероятно, будет проще всего запустить его внутри оболочки. bash будет творить чудеса в среде Linux (канал в / из файлов, запустите sed / awk / grep на выходе, чтобы проанализировать правильность). Вы можете использовать Perl или Python и их собственные соответствующие фреймворки для модульного тестирования с оговоркой, что вы должны заключить вызов вашей программы в какую-либо другую функцию: оба языка поддерживают понятие каналов из подпроцессов, python с подпроцессом модуль и Perl со стандартным механизмом открытия файлов.
Что бы вы ни делали, вы не хотите пытаться протестировать весь исполняемый файл на C ++.
Сама идея состоит в том, чтобы создать отдельный проект, в котором вы тестируете отдельные блоки кода для ожидаемого поведения независимо от здания отлаживать или нет (некоторые проблемы даже не проявляются в отладочных сборках из-за различий в коде).
Вы собираете его как двоичный файл и запускаете, чтобы убедиться, что ваши изменения ничего не сломали - часто это даже настраивается как автоматическое действие после сборки.
Если вы хотите протестировать свое приложение извне - вероятно, есть некоторые среды тестирования, которые вы можете использовать, в зависимости от области / структуры / и т. д. приложения ... Но Boost.Test и все другие среды модульного тестирования не предназначены для тестирования исполняемых файлов.