How to avoid mixing test and production code using GoogleTest?

Question

I am starting to use GoogleTest. It seems that it needs a main file for running the tests:

Separate test cases across multiple files in google test

But currently in my demo application I already have a main file:

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

Which will eventually be my "production" application. I don't want to clutter that with gtest includes, macros etc.

Should I just create another main.cpp file in another folder e.g.: test/ that will contain all the specific gtest configuration so I would end up with:

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:

Found this based on cmake:

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

which seems to be exactly what I am looking for.

You might want to switch to a different build system before your project gets big. Makefiles tend to get really convoluted for bigger projects unless you already have much experience managing makefiles. — smerlin, Feb 25 '16 at 22:04
I tend to setup a tests subdirecty for each project/library, and generate a google test binary for each test source file. That way, even if one testcase causes an application crash, all other tests and testcases will still run. (I am using `CMake` as build tool and use `ctest` to run all tests) — smerlin, Feb 25 '16 at 22:07
I always liked the idea of the tests living in a separate directory. — Daniel Kamil Kozar, Feb 25 '16 at 22:23

score 3 · Accepted Answer · answered Feb 26 '16 at 07:48

3

The most sensible approach to this is to have a library for your production code and then two executables, one for production and another one for tests:

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

Notice that gtest distribution provides the gtest library and a gtest_main library with the standard main function for your test executable. So unless you need a custom main (rare case) you don't need to provide a main.cpp for your tests and can simply link against gtest_main, e.g. $(CC) mytypetest.cpp -o apptests -lapplib -lgtest_main -lgtest.

The library approach involves slightly more complex Makefiles, but it pays off in compilation time, since not having it implies you need to compile mytype.cpp once for production application and once for test executable.

answered Feb 26 '16 at 07:48

Antonio Pérez

6,702
4
36
61

Yes it was something like that I had in mind, I found this: http://www.kaizou.org/2014/11/gtest-cmake/ that gives more details on a structure like you suggest using cmake. I will give that a try. – u123 Feb 26 '16 at 19:04
That's the source code structure I have for my current main C++ project. If you are planing to use cmake, you can benefit from its `ExternalProject` module to import the gtest libraries into your project. Find an example for this [here](https://github.com/apbarrero/cpp-utest/blob/master/test/CMakeLists.txt). – Antonio Pérez Feb 27 '16 at 10:50
Cool gonna take a look at that! Btw what editor do you use? I would like to integrate with Git and be able to build/run with a single click/short-key so I tried eclipse but it does not really do what I want: http://stackoverflow.com/questions/35668159/cmake-3-2-2-and-eclipse-4-5-1-cdt-8-0 Maybe I am a bit too ambitious here/need to go for a simpler/more manual approach? – u123 Feb 27 '16 at 13:07
I'm not a big fan of IDEs so I just use vim for small projects. I've been using QtCreator lately for a mid-size Qt project and it works quite well, it has a vim editor mode and there is a Google Test plugin. It is definitely more responsive and less cluttered then Eclipse CDT. – Antonio Pérez Feb 27 '16 at 21:10
Just tried QT Creator as you suggested and it works like a charm, this is really great and I did not have any of the problems that I had with eclipse described here: http://stackoverflow.com/questions/35673956/function-expect-call-could-not-be-resolved-cmake-gtest-and-eclipse much better impression so far with QT Creator – u123 Feb 28 '16 at 03:13

score 0 · Answer 2 · answered Feb 25 '16 at 21:57

0

There are probably a lot of ways to do this, but generally speaking, yes, you should add a test-specific main function to your project. This makes compilation a little bit more complex since you'll have to produce two separate binaries (one for your application and another for your tests) but this is a fairly typical setup.

answered Feb 25 '16 at 21:57

Ian

842
5
16

Ok makes sense, was thinking of creating just one makefile one level above the src/ and test/ folders and then put like a test and prod target in there, "make test" would create the test executable and "make prod" would create the prod executable is that against all conventions or reasonable? – u123 Feb 25 '16 at 22:02
That sounds reasonable, sure. Most Makefile projects I've worked with define separate targets for test and production executables. i.e. `make bin` will create the production binary, `make tests` will create the test executable, `make runtests` will run the tests, etc. Though, for anything larger than a toy project I'd suggest looking into CMake. It's a lot nicer than hand-editing Makefiles :) – Ian Feb 25 '16 at 22:25

score 0 · Answer 3 · answered Feb 25 '16 at 22:32

I'd simply add a test.cpp file with a main and create a test target in my makefile so that I could either make - to build my production code - or make test - to build the tests. In actual projects I use cmake in very similar fashion (I sometimes bundle all common dependencies in a core.a library and then link both main and test against it).

How to avoid mixing test and production code using GoogleTest?

3 Answers3