Now, to make the unit tests run, we need to add a fairly trivial main() method (taken from gTest’s Primer doc): 

#include "gtest/gtest.h"

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

along with the normal test fixture(s) in either one or multiple .cc files, whichever way works best for you.
(personally, I prefer the latter: one C++ class per .cc file, and the associated *_test.cc file alongside – keeps me sane!  This, obviously, requires that one just has one main() method in a separate source file, which will drive the entire test suite).


However, this will cause trouble when linking with a Debug/Release configuration, and obviously you don’t want anyway to ship your code with the tests binaries to bloat it.


This is (in theory) where the ‘Build configurations’ come into play: just exclude the *_test.cc files from Debug/Release, and equally the file containing the main() method of your program (I like to call those Main.cc and have the bare minimum to get it all started, but nothing more) be excluded from your Test configuration.


However, if you do that, and hence would not include the /include folder to all the Build Configurations (for which this would be rather pointless, as it would only be needed by the Test config) you lose the syntax highlight in all the files that make up your test fixture(s): for some reason, excluding a file from even ONE Build Configuration, confuses the hell out of CDT and the editor seems unable to cope even when the Active Configuration is the one (eg, Test) that you actually defined the file to be part of — this is bizarre, because the various configurations still build correctly and run as expected.


So here is the workaround (which is not pretty, but looks like it’s the only way to keep one’s sanity, and adds minimal hassle): just remember to add the gtest/include folder to all the build configurations settings.