Using the gtest framework to support the development of a library has three primary goals. First the environment should be organized and maintainable. Second the execution of the tests must be inclusive and repeatable by any developer. Finally, the organization should be able to support multiple developers contributing during parallel development cycles.
I have seen two approaches that provide a solution to organization question. The first approach will create a new project for each class or class collection being tested. The main advantage with this is each developer on a team has their own unit test sandbox to build all the unit tests, isolated from all the others, which they require. Scripting and batch processing will allow execution of the entire library of test by the software lead and removes the need for individual developers to execute all unit tests. The project isolation allows for good organization and is easily maintained. This approach would be excellent for very large teams of developers.
The seconds approach is to have a single project that has the entire unit test suite for the library in it. All tests must be done using the test fixture subclass, thus allowing each test to simply be a single macro entry in the main file. This approach has the advantage that everything is encapsulated in a single project; one execution tests the entire library. For small and medium size teams, the concurrent development is simple enough to maintain, since most of it should be managed by the revision control system, and every developer is easily able to run all the tests. Test actions are always encapsulated in the fixture classes.
For my project I elected to use the second approach. Being only a single developer, creating and maintaining a multiple test projects is more overhead than I need. The code organization isn
