Модульное тестирование старого кода C ++ с CPPUnit

Question

Мне поручено управлять большой базой кода, написанной на vc ++ 6.0, мне нужно начать сборку модульного теста для частей кода. Я настроил CPPUnit, и он работает с DLL моих проектов, проблема, с которой я сталкиваюсь, заключается в следующем. Устаревшее приложение состоит из 10 статических библиотек и одного огромного исполняемого приложения MFC, которое содержит 99% кода. Мой модуль модульного тестирования работает в другом проекте в том же рабочем пространстве и будет тестировать 10 библиотек без проблем, все включают и ссылки в порядке, когда я пытаюсь сделать то же самое для большого приложения MFC, я получаю ошибку компоновщика, так как у меня нет DLL для приложения. Есть ли способ провести модульное тестирование приложения, не помещая тестовый код непосредственно в приложение.

Answer 1

Мой опыт работы с юнит-тестированием обычно противоположен. Создайте проект для своего теста и импортируйте код из других проектов.

Невозможно установить связь с приложением MFC, возможно, потому что ваши функции не экспортируются. Они существуют, но не имеют возможности общаться с другими приложениями, в отличие от DLL.

Answer 2

Вы должны продолжать в том же духе:

1. У вас есть одно тестовое приложение, которое ссылается на библиотеки.
2. У вас есть одно основное приложение, которое также ссылается на эти библиотеки.

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

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

Answer 3

Если вы не можете реорганизовать свой проект, чтобы переместить бизнес-логику в новую статическую библиотеку, попробуйте связать ваш тестовый проект с промежуточными объектными файлами вашего проекта, которые вы, вероятно, можете найти в BigProject \ debug или BigProject \ debug \ obj.Вы не можете ссылаться на .EXE, как обнаружили.

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

Answer 4

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

Таким образом, в вашем решении вы получите такую ​​структуру:

MyLegacySystem.sln
  MyApplication.proj
    Main.cpp
    BusinessRules.cpp
  MyApplicationUnitTests.proj
    UnitTestsMain.cpp
    BusinessRules.cpp
    BusinessRulesTests.cpp

Если по какой-либо причине вы не можете включить свои исходные файлы в 2 проекта, вы можете извлечь источникив ваш тестовый проект, вызвав магию препроцессора:

BusinessRulesStub.cpp:
#include "..\src\BusinessRules.cpp"

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

Answer 5

Я не знаю способа связать исполняемый файл. Рефакторинг кода путем переноса бизнес-логики в DLL и оставления приложения в качестве «внешнего интерфейса» будет наиболее очевидным решением. Однако, поскольку это унаследованный код, вероятно, более уместно просто дублировать код для целей модульного тестирования. Это не идеально, и, поскольку это приложение MFC, может быть не так просто.