Great job on the article. I have three questions.
In LeapYear-Step2 you said "it is good to put the tests in a nameless namespace (will be explained later on)". But you never explained it. Why is this a good idea?
My mistake, I will add this. Basically if you have 1 unit test project for a component, then you will be testing several classes, 1 test file per class.
Then you might have several :
And if they are in each test file in a anonymous namespace, there will be no conflicts at linking time.
What if you have a console program that has a main() function. This will conflict with the main() function in the test program used to call the unit tests. What are some ways to resolve this? (The ideal solution would be one that doesn't require modifying the original source.)
I think it is best to have a dedicated project for the unit test(s), since it is intended to test units. When you have another main(), the main of the application, then the application might be to big to be a unit. The application itself can be tested. Unit tests focus on testing the building blocks, the smaller units.
Do you plan on automating the UnitTest++ program in CodeBlocks? For instance a template that will generate the "main" test source and possibly a test source for each source or class in a project file. It could also link to the UnitTest++ library and compile the library file if needed. UnitTest++ also has the capability of GUI output. The test run can be activated from a toolbar, displayed in a GUI, and clicking on an error line can then display the source and indicate the line with the error (the CodeLite IDE has this capability). It would be a useful addition to CodeBocks.
Good ideas, on my long term to-do list.
I use googletest (http://code.google.com/p/googletest/), another great framework for unit testing. The latest version of googletest, from the head of the repository, can be easily built with MinGW and Code::Blocks.
It would be nice if you could "generify" your article by separating out the UnitTest++ specific bits, and possibly indicating which parts of the project files would need to change if you want to use a different unit test framework.
As a first step I will do the article again, but then for the google-test. Thanks for pointing out google-test to me. I didn't know it.
In the mean time I already have done the first experiments, leading to a cbp file for it ;-)