7

I'm working on a large C++ project which contains more than 50 libraries and executables. I am starting to add googletest tests for each of these modules. I read that google recommends putting the tests in an executables and not in libraries to make life easier. Creating a separate executable for each separate components I would get more than 50 test executables and in order to run them all at once I would need to create an external script which would also need to combine their output to a single one. Is that the recommended thing to do?

Or should I create a library for tests of each separate module and link all these libs to a single tests executable? But then running tests for a single module becomes less convinient. I would need to build all the tests and specify to the main test executable through the gtest_filter flag which tests should be executed at this time.

It would really help me to hear how other people do this and what is the best practice here.

Thank you

Leonid Koren
  • 141
  • 1
  • 6
  • It's a bit hard to tell what should be the 'best practice' for your case, but I would go into the direction to have separate test runners for each of your modules (library). To collect the outputs and combine these into a single report would probably be most easy to do when using the JUnit-XML format (and e.g. XSLT). – πάντα ῥεῖ Nov 23 '13 at 15:56
  • What build system are you using? I think you should be able to create a single test executable for all 50 libraries, PLUS 50 test runners for inividual libraries if you wanted. My own suggestion would be to have a single test executable, but that is personal preference. What would the combined run time of all tests be? I would favor having a single executable to make it easier to perform automated testing. – NicholasM Nov 23 '13 at 20:01
  • Thanks for the two comments. I guess both aproaches suggested here might be acceptable. I think that at this point I'll choose to create a separate executable for each tested component and will combine running them all from a single external script that will also conbine their output to a single file. – Leonid Koren Nov 27 '13 at 08:51
  • @noplk1 - Did you ever figure out how to get Google Test working? I'm confused by the documentation and have a question here: http://stackoverflow.com/q/30036984/1735836 – Patricia May 04 '15 at 18:34

1 Answers1

2

[...] and in order to run them all at once I would need to create an external script which would also need to combine their output to a single one.

Maybe it's not actually necessary to combine the output into a single file. For example with Jenkins you can specify a wildcard pattern for the Google Test output files.

So if you actually just want to see the Google Test results in Jenkins (or Hudson or whatever CI tool you use), this might be a possible solution:

You would run all of your test executables from a simple script (or even from a Make rule), with parameter --gtest_output=xml: followed by a directory name (ie. ending with a slash). Every test executable will then write an own XML file into that directory, and you can then configure your CI tool to read all files from that directory.

oliver
  • 6,204
  • 9
  • 46
  • 50
  • All of our projects create gtest executables with names that start with 'gtest' and we have cmake configured to put all executables under the bin direcotory of our build directory, so I was able to translate this into `mkdir -p ${WORKSPACE}/xml/ ; find build/bin -name "gtest*" -exec {} --gtest_output=xml:${WORKSPACE}/xml/{}.xml \;` and then the wildcard worked nicely when I used `xml/build/bin/*.xml` (note that find gives the full name with {} so the extra directories are needed). – sage Jun 09 '16 at 16:37