From Freehackers
Jump to: navigation, search

by Philippe Fremy


QCppUnit is seriously obsolete. It was written in 2001 for KDE 2 with Qt 2. It won't run with recent version of Qt or KDE. Nowadays, if you need a good unit-test framework for C++, I strongly suggest to use GoogleTest which has every quality I expect from a good unit-testing framework.

Other unit-testing framework for C++:

Old introduction

QCppUnit is a framework to perform unit testing, as described for example in Extrem Programming (www.xprogramming.org ). This framework uses Qt to display the result of the tests and contains an example that show how to test a Qt application, even on user behaviour.


I took the C++ Unit test suite (called CppUnit) of one of the Extrem Programming site and ported it to Qt. My addition is the Qt Gui front-end, that runs under Unix and Windows. The testing framework itself has not been modified a lot, and I'll try to reverse the changes to have really just a Gui frontend.

What is cool with Qt is that you can test the interface of your application easily. No need for some clever replaying mechanism. Check the example 2 directory to see a real-world example.


Screenshot with failed tests Screenshot with successful tests With failed tests With success


A manual describes how to use this test framework here.

Two examples are provided in the package. For the second example, I have included a long explanation of how I tested a Qt dialog. Read it , it should be clearer than any manual.


I have been using the testing framework on Windows extensively but I hadn't written the Gui for it at that time. And I am on Linux now.

So this framework works sure on Linux with Qt2.

Linux users:

Use the Makefile, the testing framework should build without problems. Include it as is in your application (see example2 for real-world example).

Other unix users:

In the very unlikely case where the Makefile doesn't build the framework correctly, get tmake from Trolltech (www.trolltech.com ) and regenerate the Makefiles with your platform:

   find . -name \*.pro -exec touch {} \;

or manually:

   (cd qcppunit; tmake qcppunit.pro -o Makefile;)
   (cd example1; tmake example1.pro -o Makefile;)
   (cd example2; tmake example2.pro -o Makefile;)

Windows users

I haven't ported the framework to Windows with its new Gui, but it is a matter of having Windows and tmake, and spending a few minutes tweaking with the .pro files. Something like:

   cd qcppunit
   tmake -t vclib qcppunit.pro -o qcppunit.dsp
   cd ..
   cd example1
   tmake -t vcapp example1.pro -o example1.dsp
   cd ..
   cd example2
   tmake -t vcapp example2.pro -o example2.dsp
   cd ..

I'll release a clean Windows version as soon as I get back to Windows. Probably somewhere in january 2002.

Qt3 users:

I haven't compiled Qt3 yet but porting my 450 lines dialog should be no problem. I estimate the time needing to port to Qt3 to 10 minutes. I'll do it as soon as I have compiled Qt3. Somewhere in december 2001.

KDE2 users:

The framework should work without problem although it is Qt based. You don't really care if the dialog is Qt or KDE, because this test suite is only a thing you use in the development process, not something you release to the final user. You might want to change the qDebug(debugStuff) to kdDebug << debugStuff if you use setDisplayDebug(true).

KDE3 users:

Since KDE3 = Qt3 + KDE2, see the relevant previous paragraphs.

Mac OS X users:

Qt3 runs on Macos X, so should this framework. I can't test it though. Tell me if you use it on Mac OS X.


LGPL. So yes, you can use this with your proprietary, closed source, commercial, evil application :-). Beware of the Qt license though. If you don't pay for Qt, you are either with Non Commercial License, GPL or QPL. And remember, there is no warranty of anything, not even the idea that your application might not work better if you don't use this.


The latest version is the 1.0, which was released the 12/11/2001. Download it here

Unit Testing

Unit Testing is about testing in your classes everything that could possibly break. The idea is that each time you want your class to perform anything:

  • you write a test to check that your class performs correctely
  • you compile your test: some missing functions in your classes make it not compile
  • you add some empty functions in your classes so that your test compiles
  • you run your test : it fails!
  • you modify your class to make your test work, ie you implement the feature
  • you run your test : it runs!
  • if you break any other test, you fix it.

In Extrem Programming, you do this for every feature. This sounds a bit long and complicated at first glance, but when you have a 30000 lines project, and you must change some core feature that is used everywhere with two levels of indirection (understand : you don't see the result of the change directly), you are glad to have your 300 tests that will report any unexpected behaviour modification.

I give a real-world example in the example2 directory of how to use this testing suite.

Other software by Philippe Fremy

  • LuaUnit: A unit-testing framework for the Lua language
  • Klotski: a mind-breaking game
  • Indent Finder: analyse source code indentation to set your editor automatically
  • PyTiCroque: a software to help playing at www.croquemonster.com