User forums > Announcements

Unit testing in Code::Blocks

(1/4) > >>

killerbot:
Dear All,

As a long lived promise I finally finished my first article on unit testing and Code::Blocks.

It can be found at : http://wiki.codeblocks.org/index.php?title=UnitTesting

There's much more to come, but for the moment it already provides a first introduction. It even contains a Test Driven Development example, extremely simple but the easier to grasp.
I am sure the text currently contains a lot of typos, just PM them to me, and I will fix them.

FYI : the unit test framework used is UnitTest++ : http://unittest-cpp.sourceforge.net/


Cheers.

oBFusCATed:
First, great job

I've read it diagonally, because it is too much for someone who knows how it works :)
I have a comment on something you've written there:

--- Quote ---Pre-build and post-build steps are part of the build process ! Important consequence : if you want to debug something, the debugger will only kick off after Code::Blocks was able to carry out a successful build (including the pre/post builds steps). Therefor it is not wise to have the unit test executable being carried out as a post-bild step of the 'Debug' target. But as a post-build step of the Release target, our goal is met.

--- End quote ---
That is quite wrong. You 1000% want to have the tests as post-build step in the Debug target, because this is the primary target a developer is using.
And C::B should be fixed to allow this king of usage.
The fix is quite simple in the debugger if the build fails show an Annoying dialog with "Build failed, do you still want to debug the application?" (or something like that).
(I've started to do it but left it over :( )

p.s. you have many typos in the text  :lol:
p.s.s there is workaround at the moment "settings -> compiler & debugger -> debugger -> auto-build project to ensure up-to date" = off

killerbot:

--- Quote from: oBFusCATed on September 09, 2009, 05:59:22 pm ---That is quite wrong. You 1000% want to have the tests as post-build step in the Debug target, because this is the primary target a developer is using.
And C::B should be fixed to allow this king of usage.
The fix is quite simple in the debugger if the build fails show an Annoying dialog with "Build failed, do you still want to debug the application?" (or something like that).
(I've started to do it but left it over :( )

--- End quote ---

To be honest I agree.

steve:
Hi,

Well done on this article! It's great to encourage unit testing and show how it can be tightly integrated with code::blocks.

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.

jimp:
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?

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.)

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.

Navigation

[0] Message Index

[#] Next page