Мне поручено управлять большой базой кода, написанной на vc++ 6.0, мне нужно начать создавать модульные тесты для частей кода. Я настроил CPPUnit, и он работает с DLL моих проектов. Проблема, с которой я столкнулся, заключается в следующем. Устаревшее приложение состоит из 10 статических библиотек и одного огромного исполняемого приложения MFC, которое содержит 99% кода. Моя среда модульного тестирования работает в другом проекте в той же рабочей области и будет тестировать 10 библиотек без проблем, все включено, и ссылки в порядке, когда я пытаюсь сделать то же самое для большого приложения MFC, я получаю ошибку компоновщика, поскольку у меня нет dll для приложения. Есть ли способ модульного тестирования приложения без размещения тестового кода непосредственно внутри приложения.
Модульное тестирование устаревшего кода C++ с помощью CPPUnit
Ответы (5)
Вы должны продолжать, как вы:
- У вас есть одно тестовое приложение, которое ссылается на библиотеки.
- У вас есть одно основное приложение, которое также ссылается на эти библиотеки.
Либо переместите код из основного приложения в существующие библиотеки, либо, что предпочтительнее, переместите код в новые библиотеки. Тогда ваше тестовое приложение сможет получить доступ к большему количеству кода, даже не обращаясь к приложению.
Вы знаете, когда закончите, когда исходный код приложения состоит из одного модуля, который определяет main() и все остальное в библиотеках, которые тестируются тестовым приложением.
Мой опыт модульного тестирования обычно противоположный. Создайте проект для своего теста, а затем импортируйте код из других ваших проектов.
Вы не можете ссылаться на приложение MFC, вероятно, потому, что ваши функции не экспортируются. Они существуют, но не имеют средств для связи с другими приложениями, в отличие от DLL.
Я не знаю способа связать исполняемый файл. Наиболее очевидным решением будет рефакторинг кода путем переноса бизнес-логики в DLL и оставления приложения в качестве «внешнего интерфейса». Однако, поскольку это устаревший код, вероятно, более целесообразно просто продублировать код для модульного тестирования. Это не идеально, и, поскольку это приложение MFC, может быть не так просто.
Чтобы протестировать ваше основное приложение, вы можете создать тестовый проект, который включает исходные файлы, которые вы хотите протестировать - не уверен, насколько легко это сделать с помощью 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"
Однако, по сути, это временное решение. Как уже было сказано, в итоге большую часть кода следует извлечь в отдельные библиотеки.
Если вы не можете реорганизовать свой проект, чтобы переместить бизнес-логику в новую статическую библиотеку, попробуйте связать свой тестовый проект с промежуточными объектными файлами вашего проекта, которые вы, вероятно, можете найти в BigProject\debug или BigProject\debug\obj . Вы не можете ссылаться на .EXE, как вы обнаружили.
Это дает те же результаты, что и процесс копирования, предложенный Чедом, при этом избегая фактического дублирования исходного кода, что было бы очень плохо.
