"_main уже определено" при использовании gtest

Question

У меня есть решение с двумя проектами

Один из них - консольное приложение, а другой - проект Google Test

В моем проекте есть файл .h и . CPP с функцией main ()

Мой gtest состоит из файла. CPP, который вызывает файл .h с использованием #include и функцию main для RUN_ALL_TESTS ()

Мне нужен main в моем проекте, но мне также нужен main в проекте gtest, но наличие двух main () не позволяет мне успешно построить gtest

Есть ли обходной путь для этого? Извините, если это глупый вопрос, я понятия не имею, как использовать gtest, потому что разные сайты по-разному представляют

Answer 1

Прежде всего у вас должен быть выделенный файл main.cpp для функции main(), который не содержит ничего другого.

Например, структура вашего проекта может выглядеть следующим образом:

• project1
  • file1.h
  • file1.cpp
  • main.cpp

Я не знаком с Gtest в частности, но обычно для модульных тестовых сред имеется отдельный файл для основной функции gtest, например, gtest_main.cpp. Тесты находятся в одном или нескольких файлах, таких как file1test.cpp et c.

. Таким образом, вы должны скомпилировать и связать свой проект1 с file1.h, file1.cpp и main.cpp, чтобы получить исполняемый файл.

Для модульных тестов вы должны скомпилировать и связать file1.h, file1.cpp, file1test.cpp и gtest_main.cpp для исполняемого файла модульного теста.

Структура может иметь вид

• project1
  • file1.h
  • file1.cpp
  • main.cpp
• project1test
  • file1test.cpp
  • gtest_main.cpp

РЕДАКТИРОВАТЬ дополнительная информация о связывании:

В проекте project1test вы включите file1.h с #include "../project1/file1.h".

Для правильного связывания щелкните правой кнопкой мыши на project1test project

-> Свойства конфигурации -> Линкер -> Ввод -> Дополнительные зависимости -> Добавить ".. \ project1 \ Debug \ file1.obj"

Как заметил @Alan Birtles, было бы еще яснее, если бы вы имели следующую структуру:

• project1library
  • file1.h
  • file1.cpp
• project1application
  • main.cpp
• project1test
  • file1test.cpp
  • gtest_main.cpp

Вы получите статическую / динамическую c библиотеку project1library.lib/.dll, исполняемый файл project1application.exe и исполняемый модуль модульного теста project1test.exe .

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

-> Свойства конфигурации -> Линкер -> Ввод -> Дополнительные зависимости -> Добавить ".. \ project1library \ Debug \ project1library.lib"

Если у вас есть более одного файла из вашего проекта, вам не нужно добавлять каждый файл obj, но только один файл lib.

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

Answer 2

Я использовал макросы для этой проблемы. Я определил макрос TESTING, который оценивается как true при компиляции модульных тестов, а в противном случае - в false:

#ifndef TESTING
// the source main
int main() {
    ...
}
#endif // !TESTING

Вы можете также использовать это позже для «тестового» кода в ваших источниках. Что я делаю иногда (не очень хороший дизайн IMO):

class Klass:

#ifdef TESTING
    friend class KlassUnitTestClass; // allows access to private members in my google test unit class. Disabled when i build sources
#endif // !TESTING

Answer 3

Стандартное использование gtest для модульного тестирования. Обычно модульные тесты не проверяют main:).

Я рекомендую использовать стандартную основную функцию gtest (не определяйте пользовательскую основную функцию). он позволяет вам использовать командную строку для фильтрации запущенных тестов.

Если вы не хотите использовать gtest main, IMHO, вам не следует включать библиотеку gtest_main.