QCppUnit

Introduction

QCppUnit is a framework to perform unit testing, as described for example in Extrem Programming (www.xprogramming.org or www.xprogramming.com).

Origin: 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.

Warranty: As usual, no warranty for anything, not even the idea that your application will work worse if you don't use this.
Portability: 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 {} \; make

or manually:
(cd qcppunit; tmake qcppunit.pro -o Makefile;) (cd example1; tmake example1.pro -o Makefile;) (cd example2; tmake example2.pro -o Makefile;) make

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.

LICENSE

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.

Extrem Programming:

I recommend to everyone not familiar with Extrem Programming the reading of one of the three extrem programming books. Extrem Programming is about managing a software development project.

You can find a lot of information (articles, examples, comments, ...) on the official sites www.xprogramming.org and www.xprogramming.com . You can even find the complete pdf of the last book "XP installed" somewhere on these sites. There is also a french website dedicated to Extrem Programming but I can't remember the url now. You should find it with Google with 0.00000001 s

The last book (the only one I read), XP installed, is made of small chapters that use simple and clear english and are read easily. No need to concentrate very much.

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.

Feedback: Contact me for any comments: Philippe Fremy <pfremy@chez.com>