У меня есть решение Visual Studio, организованное следующим образом:
ProjectA // A static library I'm working on
ProjectB // A static library containing UnitTest++ test suites for ProjectA
ProjectC // An executable test runner which links to ProjectA and ProjectB
ProjectB содержит два файла, которые выглядят так:
// RunTests.h
#ifndef RUNTESTS_H
#define RUNTESTS_H
#include "UnitTest++.h"
int runAllTests();
#endif
и это:
// RunTests.cpp
#include "RunTests.h"int runAllTests()
{
return UnitTest::RunAllTests();
}
А также несколько файлов, содержащих тестовые наборы, например:
// FooTests.cpp
#include "RunTests.h" //
#include "Foo.h" // From ProjectA
TEST(SomeTest)
{
CHECK(true);
}
ProjectC состоит из одного файла:
// main.cpp
#include "RunTests.h" // from ProjectB
int main()
{
return runAllTests();
}
Причина, по которой я разделил тесты и тестовый прогон, заключается в том, что у меня есть другой проект, в котором используются те же тесты для анализа покрытия кода, который мне нужно разделять, поскольку он не кроссплатформенный, в отличие от тестового прогона.
Проблема в том, что когда я компилирую и запускаю ProjectC, никакие тесты фактически не запускаются (UnitTest ++ запускается, но с нулевыми тестами). Это потому, что ProjectC не ссылается ни на какие символы, относящиеся к тестам из ProjectB, поэтому компоновщик не связывает объектные файлы из ProjectB.lib.
Насколько я понимаю, если бы ProjectB был исполняемым файлом, у меня не было бы этой проблемы (предположительно, потому что компоновщик связывал бы все объектные файлы), согласно документации:
Общая идея заключается в том, что вы сохраняете один файл Main.cpp с
точка входа, которая вызывает RunAllTests ().Затем вы можете просто скомпилировать и связать новые файлы .cpp по желанию, как правило,
по одному на тестовый набор.Каждый из файлов Test * .cpp будет содержать одно или несколько заклинаний макроса TEST со связанным
тестовый код. Нет никаких исходных зависимостей между Main.cpp и
Протестируйте * .cpp, так как макрос TEST обрабатывает регистрацию и настройку
необходимо для RunAllTests () найти все тесты, скомпилированные в один и тот же
финальный исполняемый файл
Как я могу решить эту проблему, не объявляя все тесты в заголовочных файлах, которые может видеть ProjectC (что может убить простоту использования UnitTest ++)? Одна возможность, которую я заметил в Visual Studio:
Настройки проекта> Свойства конфигурации> Линкер> Ввод> Форсировать ссылки на символы
Однако было бы довольно утомительно добавлять каждый символ каждый раз, когда я пишу новый модульный тест. Есть ли какой-нибудь способ заставить его включить все содержимое ProjectB.lib? Или, может быть, какое-то решение на основе кода?
РЕДАКТИРОВАТЬ: То, что я ищу, это что-то вроде этот но для Visual Studio.
Я пытался использовать UnitTest ++ так же, как вы описали, и столкнулся с той же проблемой. Я наткнулся на предложение на другом форуме, которое, кажется, работает для моего исполняемого файла unittest (то есть ProjectC).
Для ProjectC:
Настройки проекта> Общие свойства> (выберите ProjectB)> Использовать входы зависимостей библиотеки: True
Это сработало для меня. Я думаю, что это эффективно связывает любые объектные файлы из ProjectB в ProjectC (в отличие от связывания библиотеки).
Других решений пока нет …