Настройка Visual C ++ TDD - PullRequest
Новая
       41

Настройка Visual C ++ TDD

3 голосов
/ 18 ноября 2008

Я мало работал с Visual Studio раньше. Я начал свой личный проект в свое свободное время, и я хотел бы использовать разработку, основанную на тестировании, поскольку она принесла мне огромную пользу при разработке Java. Я начал этот проект довольно давно, и я использовал CppUnit. Я знаю, что, вероятно, есть и другие фреймворки, которые лучше, но это то, что уже есть.

В моем решении Visual Stuido 2005 есть 2 проекта. Это работало нормально, когда модульные тесты располагались рядом с кодом приложения. По мере того, как проект увеличивался в размерах, он становился довольно громоздким и не элегантным. Я создал новый проект под мое решение для размещения модульных тестов (так что теперь у него есть 3 проекта). Все прошло хорошо, пока я не попытался построить решение. Все скомпилировано, но проект модульного теста не удалось связать. Вывод дает мне 51 «неразрешенную внешнюю символьную» ошибку (LNK2019) для того, что похоже на каждую функцию, которую вызывают мои тесты.

Насколько я могу понять, проблема в структуре каталогов, которую создает Visual Studio. Каждый проект получает свой собственный каталог, а затем ниже создаются объектные файлы и исполняемые файлы. Я думаю, проблема в том, что, хотя заголовочные файлы правильно включены в каждый модульный тест, компоновщик не может найти файлы cpp, потому что они находятся в другом каталоге. Когда не удается найти реализацию вызываемой функции, выдается ошибка 2019 года.

Прав ли я в своей оценке проблемы? Как я могу это исправить? Нужно ли полностью реорганизовывать мои проекты или это простая конфигурация компоновщика?

Спасибо

Ответы [ 3 ]

1 голос
/ 25 ноября 2008

Похоже, что функции / классы, которые ваш тестовый проект использует из ваших основных проектов, не экспортируются. Если код не экспортируется, то ничего кроме DLL / EXE-файла, в котором находится код, не может ссылаться на него.

Обычный способ справиться с этим - добавить определение в проект (в настройках проекта перейдите в Свойства конфигурации -> C / C ++ -> Препроцессор, в первой строке есть определения), называемое PROJECTNAME_IMPL (убедитесь, что вы делаете это для конфигураций Debug и Release!). Затем есть файл заголовка (называемый ProjectNameExport.h), который включает в себя все экспортируемые файлы, который содержит что-то вроде следующего: 

#ifdef PROJECTNAME_IMPL
    #define PROJECTNAME_API __declspec(dllexport)
#else
    #define PROJECTNAME_API __declspec(dllimport)
#endif

Затем при определении класса (например): 

#include "ProjectNameExport.h"

class PROJECTNAME_API Foo
{
};

Результатом является экспорт класса, когда файл заголовка включен в файл в проекте, и импорт класса, когда файл заголовка включен в файл в другом проекте (который, конечно, ссылается на первый проект) ).

1 голос
/ 25 ноября 2008

Я всегда добавляю тестируемый код в отдельный статический файл .lib, и от этого зависят EXE-файл основного приложения и EXE-модульные тесты. Добавлен новый код .lib project, а поддержка зависимостей обеспечивает ссылку на EXE-файлы без ошибок. Вы должны убедиться, что проекты EXE могут найти заголовки .lib, но это будет зависеть от вашей структуры каталогов. Вы также должны следить за тем, чтобы .lib и EXE-файлы использовали одну и ту же библиотеку CRT / MFC (например, при использовании CRT вы можете статически связываться с ним или использовать DLL).

Мне проще использовать libs таким способом, чем добавлять файлы / заголовки в несколько проектов.

Я использую тестовую среду Boost, но я бы структурировал ее одинаково, независимо от структуры TDD.

Хорошую статью о подобной настройке можно найти здесь:

http://www.codeproject.com/KB/architecture/Designing_Robust_Objects.aspx

1 голос
/ 18 ноября 2008

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

...