I am introducing Google Test into our development environment at work, and would like to encourage a TDD mindset, making this as accessible as possible for new developers to start using. I am looking for recommendations on standard project structure to follow for relatively simple C++ Eclipse projects. These would generally be of the order of around 10-30 classes for engineering projects.

I am currently organizing the folders in this fashion:

  1. src
  2. include
  3. test
  4. gtest_src

Also, is it recommended for testing to split any project into three sub projects?


  1. Library (for testing)
  2. Executable project
  3. Test project

Should 1. and 3. be combined into one project?

I am coming back to C++ after a while with more focus on C# and Python and this structure seems a bit painful for every new project.

  • 1
    What would be in the library? Is the executable project just a main with some code to drive the classes in the library?
    – Iker
    Mar 4, 2016 at 9:11
  • 1
    Yes exactly, that was my thoughts. I was thinking splitting the code into a library would be easier for testing.
    – C Mars
    Mar 4, 2016 at 10:58
  • By all means, create a lib straight from the beginning. It not only helps when doing TDD but makes it harder to do stupid things (such as parsing the command line in core classes). Tools such as CMake make it a breeze.
    – user44761
    Mar 4, 2016 at 15:11

1 Answer 1


Adding this as an answer ( because long :) ), but the "best" structure of your project is subjective.

I tend to apply this exact architecture for my C++ projects, both at home (CMake + XCode) and at work (Visual Studio):

  • use separate unit test library (your gtest_src)
  • use static libraries implementing core functionality
  • use thin executable applications
  • use separate applications for testing.

It is a good idea to keep the tests separate from the code (either as another extra library, or written directly into the test applications.

At home, I have the following:

static libs:

  • unittest (unit testing static lib)
  • logging (logging static lib)
  • net (networking primitives static lib)
  • tools (generic, reusable code and tools, algorithms, etc)

test libs:

  • unittest-tests (dynamic tests lib)
  • logging-tests (dynamic tests lib)
  • net-tests (dynamic tests lib)
  • tools-tests (dynamic tests lib)

  • test-runner (app) (works with the test libs passed as input cli arguments)
  • various other network applications

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.