Настройка Visual C++ TDD
Раньше я мало работал с Visual Studio. В свободное время я начал личный проект и хотел бы использовать разработку, основанную на тестировании, поскольку это принесло мне огромную пользу при разработке Java. Я начал этот проект довольно давно и использовал CppUnit. Я знаю, что, вероятно, есть другие фреймворки, которые лучше, но это то, что уже существует.
В моем решении Visual Stuido 2005 есть 2 проекта. Он работал нормально, когда модульные тесты располагались рядом с кодом приложения. По мере роста проекта он становился довольно громоздким и неэлегантным. Я создал новый проект в рамках своего решения для размещения модульных тестов (теперь у него 3 проекта). Все шло нормально, пока я не попытался создать решение. Все скомпилировано, но не удалось связать проект модульного теста. Результат дает мне 51 ошибку «неразрешенного внешнего символа» (LNK2019) для каждой функции, которую вызывают мои тесты.
Насколько я могу понять, проблема заключается в структуре каталогов, которую создает Visual Studio. Каждый проект получает свой собственный каталог, а под ним создаются объектные файлы и исполняемые файлы. Я думаю, проблема в том, что, хотя файлы заголовков правильно включены в каждый модульный тест, компоновщик не может найти файлы cpp, потому что они находятся в другом каталоге. Когда он не может найти реализацию вызываемой функции, он выдает ошибку 2019.
Прав ли я в своей оценке проблемы? Как я могу это исправить? Мне нужно полностью реорганизовать мои проекты или это простая настройка компоновщика?
Спасибо
Ответы 3
Да, ваша оценка звучит неплохо. Попробуйте следующее: в обозревателе решений щелкните правой кнопкой мыши имя проекта, который содержит ваши тесты, и выберите «Зависимости проекта». Поставьте галочку у каждого проекта, от которого он зависит. Это должно настроить параметры компоновщика, чтобы он автоматически мог найти правильные файлы.
Похоже, что функции / классы, которые использует ваш тестовый проект из ваших основных проектов, не экспортируются. Если код не экспортируется, то ничто за пределами библиотеки DLL / exe, в которой находится код, не может ссылаться на него.
Обычный способ, которым мы справляемся с этим, - это добавить определение в проект (в настройках проекта перейдите в Свойства конфигурации -> C / C++ -> Препроцессор, первая строка содержит определения), называемое чем-то вроде PROJECTNAME_IMPL (убедитесь, что вы сделали это как для конфигурации отладки, так и для конфигурации выпуска!). Затем есть файл заголовка (называемый ProjectNameExport.h), который включает все экспортируемое, и который содержит что-то вроде следующего:
#ifdef PROJECTNAME_IMPL
#define PROJECTNAME_API __declspec(dllexport)
#else
#define PROJECTNAME_API __declspec(dllimport)
#endif
Затем при определении класса (например):
#include "ProjectNameExport.h"
class PROJECTNAME_API Foo
{
};
Это приводит к экспорту класса, когда файл заголовка включен в файл внутри проекта, и к импорту класса, когда файл заголовка включен в файл в другом проекте (который, конечно, связан с первым проектом).
Я всегда добавляю тестируемый код в отдельный статический файл .lib, и от этого зависят EXE основного приложения и модульные тесты EXE. Новый код добавлен в проект .lib, а поддержка зависимостей гарантирует, что ссылки EXE не содержат ошибок. Вам необходимо убедиться, что проекты EXE могут найти заголовки .lib, но это будет зависеть от вашей структуры каталогов. Вы также должны следить за тем, чтобы .lib и EXE используют одну и ту же библиотеку CRT / MFC (например, при использовании CRT вы можете статически связываться с ней или использовать DLL).
Я считаю, что использовать библиотеки таким образом легче, чем добавлять файлы / заголовки в несколько проектов.
Я использую тестовую среду Boost, но я бы структурировал ее одинаково, независимо от структуры TDD.
Хорошую статью о подобной настройке можно найти здесь:
http://www.codeproject.com/KB/architecture/Designing_Robust_Objects.aspx
Спасибо за предложение, но, к сожалению, это была одна из первых вещей, которые я попробовал, и это не сработало.