What is an effective way to organize C ++ projects that will be tested on a module?

Question

I am wondering what would be an effective way to organize C ++ projects and classes that will be tested on a module. I read a lot of SO posts related to unit test but did not find practical examples.

Here are some of the ways I have put together:

Method a

• Project A : An application project (.exe) that "includes" classes from Project C
• Project B : unit test (.exe) a project that includes classes from Project C
• Project C : The Static library project (.lib), which supports all the classes used in Project A

Method B

• Project A : an application (.exe) with all classes within itself.
• Project B : unit test (.exe) a project that "binds" to classes in project A

Method C (from Miguel)

• only one project with three configurations:
  • Debugging: Creates a .exe application in debug mode.
  • Release: creates your .exe application in release mode.
  • Test: creates a unit test structure, replaces your main () application with the main test module ()

What is the most suitable way? Do you have any other suggestions?

Answer 1

I used the first method before. Have most of your code in a static library project, the main executable project just has the main function, and you have your tests and the main test function in the third project. Two executable projects will reference the static library and reuse the code.

The main advantages are:

• Checked code is the same as in your application.
• You can test both debug and release configurations so that both work properly. (You can extrapolate debugging and release for any configurations that may be required.)
• Build time is minimized because both executable projects use the same built-in library.
• Can the build system create both the test and the main executable file at the same time, and also run the test executable after it is created.

Answer 2

Actually there are not many differences, since you can always compile exe as a static library and a link to unit tests. Conceptually, method A is a little cleaner, but nothing prevents you from using method B. It basically comes down to your build system, which is easier to do.

Answer 3

I do not think that you will greatly benefit by moving your application classes to a static library. You should also consider that you may want to change your classes when compiling them for testing, for example, by adding additional convenient methods that are not needed for the application, therefore, in the end, placing classes in the library may not help at all, because you will need a special version these classes when running tests.

I would suggest the following as a better option than your methods A and B:

METHOD C

• only one project with three configurations:
  • Debugging: Creates a .exe application in debug mode.
  • Release: creates your .exe application in release mode.
  • Test: creates a unit test structure, replaces your main () application with the main test module ()

If you think you need it, you can split the test target into Debug and Release.