Best Practices Question

[Michael Bailey]

I apologize if this is a stupid question. I very new to Google Test,
but am excited to learn more.

In the past we have generally broken our test cases out into separate
files which we build individually and execute as test cases. It seems
like the general method of writing tests with Google Test is to write
the test code inline with the operational code. Is that correct? Is
that the best route to take, or is it wise to keep the test code in
separate files which are linked in just for testing purposes?

[Keith Ray]

Depends on how you want to structure your projects. You could have, for example, class-name.cpp, class-name.h, class-name-tests.cpp in one directory, or two, or three.

And 2 or 3 or more build targets: project.exe (release build), project-tests.exe, project-debug.exe, maybe 1 more target for measuring performance.

I don't recommend multiple executables for all your tests. I want my tests to run quickly and often. Gtest makes running a subset of tests pretty easy. Ask yourself why do you want more than one exe for your tests? Does the reason imply a poor design? (e.g. global state can't easily be cleaned up.) Maybe you should fix that instead of working around a problem by how you test.

C. Keith Ray

Amplify Your Agility
Coaching | Training | Assessment | eLearning
http://industriallogic.com

[Bala Natarajan]

Hi

Keith answered your question, but I wanted to provide another
perspective, inline with what he says.

Good thing about google test is that it doesn't ascribe or prescribe
anything. You can fit things the way you want in your environment. I
work for PayPal during the day, and I use google test heavily at work.
I use google test outside production code, and make it link with the
library that I am testing. I split tests in to multiple files (easier
to manage tests), but create just one executable. My colleagues are
writing tests as I do, and I have requested them to keep things in
separate executables during the dev phase, and I plan to make them
into a single executable once we are moving over to another feature.
This helps with parallel development to start without having to worry
about treading on each others toes.

We use g++ heavily at work, and I have had kick running gcov, along
with lcov to see coverage as I write tests. Worthy exercise. Have fun!

Thanks
Bala

[Michael Bailey]

In general, the reason why we have had separate executables wasn't so
much a design choice as much as just the way we started doing things.
It was one of those legacy sort of things. That said, when benefit of
having separate executables is the ease of dealing with tests which
fail by way of segmentation faults. It seems that these would cause
all subsequent tests to not be run. But, then again, perhaps that is
acceptable due to the severe nature of a segmentation fault.

In any case, thank you for your help. I think I will probably take
the route, at the moment at least, of just placing the tests inline
with the code. It seems that this will provide the ability to
leverage the already existant link rules. I can simply replace the
main() function for my test entry. This saves the team from having to
add new cpp files in two places. Let me know if I am missing
something, if that sounds like a bad idea.

Thanks again for the help.

On Nov 14, 2:52 pm, Keith Ray <keith....@gmail.com> wrote:
> Depends on how you want to structure your projects. You could have, for example, class-name.cpp, class-name.h, class-name-tests.cpp in one directory, or two, or three.
>
> And 2 or 3 or more build targets: project.exe (release build), project-tests.exe, project-debug.exe, maybe 1 more target for measuring performance.
>
> I don't recommend multiple executables for all your tests. I want my tests to run quickly and often. Gtest makes running a subset of tests pretty easy. Ask yourself why do you want more than one exe for your tests? Does the reason imply a poor design? (e.g. global state can't easily be cleaned up.) Maybe you should fix that instead of working around a problem by how you test.
>
> C. Keith Ray
>
> Amplify Your Agility

> Coaching | Training | Assessment | eLearninghttp://industriallogic.com

[Vlad Losev]

Hi Michael,

I would like to present an argument regarding combining your tests with your production code. Usually tests are written with considerations different from those of production code. After correctness, for production code code security, performance, and and code reuse matter the most. For test code readability is more important. Without understanding the meaning of the test, it's impossible to tell whether the test itself is correct.

In case of bundling tests security comes into play. You probably don't spend as much attention on security of your tests as on security of your production code, and you shouldn't — unless those tests end up in the code you ship or expose to users in any other way. If your tests sit together with your production code, you must have a build process that filters them out of your binaries. If you never combine your tests with your production code, you don't need to clean them out.

Regards,

Vlad