Модульное тестирование исполняемого проекта - PullRequest
Новая
       5

Модульное тестирование исполняемого проекта

12 голосов
/ 15 декабря 2009

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

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

#ifdef _DEBUG
    BOOST_AUTO_TEST_CASE( my_func )
    {
    }
#endif

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

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

Есть мысли или идеи?

Ответы [ 5 ]

7 голосов
/ 15 декабря 2009

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

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

6 голосов
/ 15 декабря 2009

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

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

3 голосов
/ 15 декабря 2009

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

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

2 голосов
/ 01 ноября 2017

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

Как и я:

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

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

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

1 голос
/ 15 декабря 2009

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

Введите:

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

Выход:

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

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

Что бы вы ни делали, вы не хотите попробовать выполнить модульное тестирование всего исполняемого файла из C ++.

...