Единичное тестирование исполняемого проекта

Возможно, я не думаю об этом правильно. Я начинаю свой второй проект с помощью модульных тестов. Мой первый проект, который я выполнил самостоятельно, для этого проекта я тестирую Boost:: test.

Мой вопрос: каковы надлежащие процедуры для проектов модульного тестирования, которые компилируются в исполняемые файлы? Кажется, все, что я вижу, есть для библиотек и зависимостей. Я хочу, чтобы проект exe был протестирован модулем, но мне не нужна куча функций unit test, плавающих в двоичном формате, и я не хочу делать

#ifdef _DEBUG
    BOOST_AUTO_TEST_CASE( my_func )
    {
    }
#endif

вокруг всех моих тестов.

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

Любые мысли или идеи?

Ответы

Ответ 1

Проект может быть скомпилирован как библиотека, и эта библиотека связана, возможно, статически, в двух отдельных исполняемых файлах: "проект", который будет доставлен, и модульные тесты.

Теперь проблема возникает из вашей среды IDE, какой она? Позволяет ли создать два двоичных файла для одного проекта?

Ответ 2

Я использую cppunit для тестирования моих исполняемых файлов в дополнительном проекте, который просто ссылается на *.obj файлы, созданные из кода исполняемых файлов. Таким образом, у вас нет тестовой логики в исходной базе кода и вы можете написать отдельную консоль или приложение Windows для своих тестов.

Приветствия Хольгер

Ответ 3

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

Если вы хотите протестировать свое приложение извне - есть, вероятно, некоторые рамки тестирования, которые вы можете использовать, в зависимости от области/рамки/etc. приложения... Но Boost.Test и все остальные модульные модули тестирования не предназначены для тестирования исполняемых файлов.

Ответ 4

Групповое тестирование исполняемого файла может быть отличной идеей - но поймите, что это совершенно другой монстр, чем код модульного тестирования. Когда у вас есть исполняемый файл, больше нет С++ или Boost. Это просто программа. Вы должны иметь возможность запускать его и анализировать/управлять своими входами в другом механизме:

Input:

  • аргументы
  • stdin
  • переменные окружения (возможно)
  • файлы конфигурации (возможно)

Вывод:

  • возвращаемое значение
  • stdout
  • выходные файлы (возможно)

Вероятно, будет проще всего запустить его внутри оболочки. bash будет творить чудеса в среде Linux (из файлов в трубку/из файлов, запустите sed/awk/grep на выходе, чтобы проанализировать правильность). Вы можете использовать Perl или Python и свои собственные структуры модульного тестирования, с оговоркой, что вам нужно обернуть вызов вашей программы в какой-то другой функции: оба языка поддерживают понятие труб из подпроцессов, python с модулем subprocess и Perl с его стандартным механизмом открытия файлов.

Независимо от того, что вы делаете, вы не хотите пытаться выполнить единичный тест всего исполняемого файла из С++.

Ответ 5

Вы можете включить необходимый .cpp файл из своего проекта unit test и протестировать его.

Как и я:

Тесты\Gameserver\PVESettingsTest.cpp:

#include "../../sources/GameServer/PVESettings.cpp"

Все работает отлично...