http://wiki.codeblocks.org/index.php?title=UnitTesting
this is quit simple, the wiki article describes on how to do it though, but you are right it doesn't show an example.
Typically your classes will be packaged in a library (static or dynamic), and in the end your application will use one or more libraries and will link with those libraries.
Well a unit test is nothing more then another application using one or more libraries (preferably only the one under test).
So in your unit test application add the include directory of your library, and link with the deliverable of the library project (aka the library binary).
So basically take the same approach as you would do when you have an application using a library.
Slix:
The approach I take is a bit different, I don't create static/dynamic libraries. I just create the unit testing project then add all test_*.cpp files that do the tests, then I fix all undefined symbol errors by adding the relevant .cpp files.
This way I can set the unittest project as a dependency of the project I'm testing and when I build the main project the unit test project is build and the tests are run.
Note also : that project dependencies are stored within a workspace (just like VS), I personally would like this to be stored in the project itself, that way if I would use several workspaces I don't have to respecify this.+1 8)
on your first remark. Yes, project dependencies is something that CB is still lacking a bit (compared for example to VS).
I usually do this (I assume always using the release build of unittest++ library) :
1) library project which has 2 targets : debug and release
2) unit test project which has 2 targets : debug and release
Here it comes :
* I save the workspace and in the workspace I set 2) to e dependent on 1)
* 2:debug:linker settings --> 1:debug:library delivery [meaning I already build 1 so I can select the lib or I manually type it in in case 1 is not build yet]
* 2:release:linker settings --> 1:release:library delivery
AND to really have full dependency checking :
* 2:debug [through project properties : build targets : external dependencies : external dependency files : specify again the 1:debug:library delivery]
* 2:release [through project properties : build targets : external dependencies : external dependency files : specify again the 1:release:library delivery]
Now all will go automatically :
* say the unit tests is the active project, and you changed some file of the library, when you build the unit tests it will check the dependencies and will rebuild it's buddy debug/release library and (recompile in case it was something of headers its including) and relink.
I admit, we should have something like project B depends on project A, and it targets have the same name all these dependency things come out of the box for free. But currently it is not. The 2 extra steps I mentioned after the "AND to really ..." are needed.
Note also : that project dependencies are stored within a workspace (just like VS), I personally would like this to be stored in the project itself, that way if I would use several workspaces I don't have to respecify this.
Run the test executable as a post build and make it print its output to stdout or stderr
#include "firsttests.h"
#include "myTic.h"
#include "UnitTest++.h"
TEST( OneForTheRoad)
{
MyTic theTick;
float theLimit = theTick.getLimit();
} MyTic theTick = MyTic::MyTic();
const float theLimit = theTick.getLimit();