Как избежать смешивания тестового и производственного кода с помощью GoogleTest?

Я начинаю использовать GoogleTest. Кажется, что он нуждается в основной файл для запуска тестов:Как избежать смешивания тестового и производственного кода с помощью GoogleTest?

Separate test cases across multiple files in google test

Но в настоящее время в моем демо-приложения У меня уже есть основной файл:

src/ 
-> MyType.h 
-> main.cpp 
-> Makefile

который в конечном итоге будет мой «производство» заявление. Я не хочу загромождать, что с GTEST включает в себя, макросы и т.д.

Должен ли я просто создать еще один файл main.cpp в другую папку, например: test/, которая будет содержать всю специфическую конфигурацию GTEST, так что я бы в конечном итоге с:

src/ 
-> MyType.h 
-> main.cpp 
-> Makefile // Makefile for producing production code/binaries 
Test/ 
-> MyTypeTest.h // Unittest for MyType 
-> main.cpp // The "Test runner" 
-> Makefile // Makefile for producing test executable

EDIT:

Нашел на основе CMake:

http://www.kaizou.org/2014/11/gtest-cmake/

который, кажется, именно то, что я ищу.

источник

2016-02-25 u123

Возможно, вы захотите переключиться на другую систему сборки до того, как ваш проект станет большим. Makefiles, как правило, действительно запутаны для больших проектов, если у вас уже нет большого опыта управления make-файлами. – smerlin

Я имею тенденцию настраивать поддиректорию тестов для каждого проекта/библиотеки и генерировать бинарный тест google для каждого тестового исходного файла. Таким образом, даже если один тестовый файл вызывает сбои приложения, все остальные тесты и тестовые теги будут выполняться. (Я использую 'CMake' как инструмент сборки и использую' ctest' для запуска всех тестов) – smerlin

Мне всегда нравилась идея тестов, живущих в отдельном каталоге. –

Самый разумный подход к этому должен иметь библиотеку для производства кода, а затем два исполняемых файлов, один для производства и еще один для испытаний:

|-lib/ 
| |-Makefile 
| |-mytype.h 
| `-mytype.cpp 
|-app/ 
| |-Makefile 
| `-main.cpp 
`-test/ 
    |-Makefile 
    `-mytypetest.cpp

Обратите внимание, что GTEST распределение обеспечивает gtest библиотека и gtest_main библиотека со стандартной основной функцией для вашего тестового исполняемого файла. Поэтому, если вам не нужен специальный основной (редкий случай), вам не нужно указывать main.cpp для ваших тестов и можете просто связать его с gtest_main, например. $(CC) mytypetest.cpp -o apptests -lapplib -lgtest_main -lgtest.

Подход к библиотеке включает в себя несколько более сложный Makefile, но он окупается во время компиляции, поскольку не имеет в виду, что вам нужно скомпилировать mytype.cpp один раз для производственного приложения и один раз для тестового исполняемого файла.

источник

2016-02-26 07:48:54

Да, это было что-то вроде того, что я имел в виду, я нашел это: http://www.kaizou.org/2014/11/gtest-cmake/, который дает более подробную информацию о структура, как вы предлагаете использовать cmake. Я попробую. – u123

Это структура исходного кода, которая у меня есть для моего текущего основного проекта на C++. Если вы планируете использовать cmake, вы можете воспользоваться его модулем 'ExternalProject', чтобы импортировать библиотеки gtest в ваш проект. Найдите пример для этого [здесь] (https://github.com/apbarrero/cpp-utest/blob/master/test/CMakeLists.txt). –

Круто посмотрим! Кстати, какой редактор вы используете? Я хотел бы интегрироваться с Git и иметь возможность создавать/запускать с помощью одного клика/короткого ключа, поэтому я попытался затмение, но он действительно не делает то, что я хочу: http://stackoverflow.com/questions/35668159/cmake- 3-2-2-и-eclipse-4-5-1-cdt-8-0 Может быть, я слишком амбициозен здесь/должен пойти на более простой/более ручной подход? – u123

Возможно, есть много способов сделать это, но, вообще говоря, да, вы должны добавить в свой проект основную функцию, специфичную для теста. Это делает компиляцию немного более сложной, так как вам придется создавать два отдельных бинарных файла (один для вашего приложения и другой для ваших тестов), но это довольно типичная настройка.

источник

2016-02-25 21:57:47 Ian

ОК имеет смысл, думал о создании всего лишь одного makefile на один уровень выше src/и тестовых/папок, а затем помещался как тестовая и prod-мишень там, «make test» создавал бы тестовый исполняемый файл и «make prod» создавал бы исполняемый файл prod - это то, что против всех конвенций или разумных? – u123

Звучит разумно, конечно. Большинство проектов Makefile, с которыми я работал, определяют отдельные цели для тестовых и производственных исполняемых файлов. то есть «make bin» создаст производственный двоичный файл, «make tests» создаст тестовый исполняемый файл, «make runtests» запустит тесты и т. д. Хотя для чего-то большего, чем игрушечный проект, я бы предложил посмотреть на CMake. Это намного приятнее, чем ручная редактирование Makefiles :) – Ian

Я просто добавить test.cpp файл с основным и создать test цель в моей Makefile, так что я мог или make - построить свой производственный код - или make test - построить тесты. В реальных проектах я использую cmake очень похожим образом (я иногда связываю все общие зависимости в библиотеке core.a, а затем связываю как основной, так и тест против него).

источник

2016-02-25 22:32:50

Как избежать смешивания тестового и производственного кода с помощью GoogleTest?

ответ

Смежные вопросы