What is your favorite/recommended project structure and file structure for Unit Testing using Boost?

I have not used Unit Testing so far, and I intend to adopt this procedure. I was impressed by TDD and certainly want to give it a try - I'm almost sure it's the way to go.

Boost looks like a good choice, mainly because it's being maintained. With that said, how should I go about implementing a working and elegant file-structure and project-structure ? I am us开发者_Python百科ing VS 2005 in Win XP. I have been googling about this and was more confused than enlightened.

Our Boost based Testing structure looks like this:

ProjectRoot/
  Library1/
    lib1.vcproj
    lib1.cpp
    classX.cpp
    ...
  Library2/
    lib2.vcproj
    lib2.cpp
    toolB.cpp
    classY.cpp
    ...
  MainExecutable/
    main.cpp
    toolA.cpp
    toolB.cpp
    classZ.cpp
    ...
  Tests/
    unittests.sln
    ut_lib1/
      ut_lib1.vcproj (referencing the lib1 project)
      ut_lib1.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib1
      ut_classX.cpp - testing of a class or other entity might be split 
                      into a separate test file for size reasons or if the entity
                      is not part of the public interface of the library
      ...
    ut_lib2/
      ut_lib2.vcproj (referencing the lib2 project)
      ut_lib2.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib2
      ...
    ut_toolA/
      ut_toolA.vcproj (referencing the toolA.cpp file)
      ut_toolA.cpp - testing functions of toolA
    ut_toolB/
      ut_toolB.vcproj (referencing the toolB.cpp file)
      ut_toolB.cpp - testing functions of toolB
    ut_main/
      ut_main.vcproj (referencing all required cpp files from the main project)
      ut_classZ.cpp - testing classZ
      ...

This structure was chosen for a legacy project, where we had to decide on a case-by-case basis on what tests to add and how to group test-projects for existing modules of sourcecode.

Things to note:

• Unit Testing code is always compiled separately from production code.
• Production projects do not reference the unit testing code.
• Unit Testing projects include source-files directly or only reference libraries, depending on what makes sense given the use of a certain code-file.
• Running the unit tests is done via a post-build step in each ut_*.vcproj
• All our production builds automatically also run the unit tests. (In our build scripts.)

In our real (C++) world you have to make tradeoffs btw. legacy issues, developer convenience, compile times, etc. I think our project structure is a good tradeoff. :-)

I spilt my core code up into either .libs or .dlls and then have my Boost test projects depend on these lib/dll projects. So I might end up with:

ProjectRoot
  Lib1Source
    Lib1Tests
  Lib2Source
    Lib2Tests

The alternative is to store your source in a separate folder and add the files to both your main apps project and the unit test project but I find this a little messy. YMMV.