Switching to QtTestLib for unit tests

[David Faure]

It's bad timing as usual. After talking to Trolltech about QtTestLib-3 last year
and waiting for a very very long time for them GPL'ing it, and nothing happened,
we went forward with kunittest.

But now Trolltech has GPL'ed QtTestLib-4, which is really much nicer than the
previous version of QtTestLib.
See http://www.trolltech.com/products/solutions/catalog/4/Tools/qttestlib/

I wasn't initially in favour of switching to qttestlib, but then I saw Harald's presentation
of it (see below for a list of advantages), and I also ran into problems with kunittest:
the whole idea of dlopened modules falls apart in kdelibs. The test module links
to libkdecore.so, and when dlopening it from kunittestmodrunner it would use
the system libkdecore.so instead of the one in ../.libs. Libtool can use local libs
when launching a program, but there's no solution for dlopening modules.
My reason for pushing dlopened modules was to simplify the code to write for
each test program, but another solution for that is simply a macro containing the whole
main() of the test program, like qttestlib does.

Here's a list of other things that qttestlib provides over kunittest:

* More flexible data-type support (one can't do CHECK(QStringList,QStringList) with kunittest
because that type isn't printable with <<, for instance; qttestlib uses template specialization
so it works fine there)
* Data-driven testing (see the online tutorial)
* GUI automation (send fake key events and mouse events to widgets)
* Signal introspection (count how many times a signal was emitted, and check with which values)
* XML output (for GUIs)
* Verbose output (shows variable values also in working tests) / signal slot dumper
* Comments attached with expected failures
* Additional message can be passed to VERIFY macro check, e.g. DB error message.
* Support for checking that a qDebug/qWarning message was shown
* Simpler framework (no test runner, and no GUI)

But of course the idea would be that the kdesdk/kunittest GUI could be ported
to qttestlib. I don't plan on working on that myself though, my main use for unit-testing
is "make check" type of thing, mostly in kdelibs.

And for the non-technical advantages:
* maintainance and bugfixing done by Trolltech (Harald will keep our copy in sync)
* using the same unittest framework as Qt makes KDE development closer to Qt
development. Someone writing KDE applications can switch to writing a Qt applications
now and then, and vice-versa, without having to learn two unit test systems.

I thought the GPL license of qttestlib could be a problem, but in fact qtteslib
is just like Qt: GPL for opensource development, and available to commercial
Qt customers via Qt Solutions. No problem.

If you wonder what switching would mean: see attached diff for ktempfiletest,
including the full diff for importing qttestlib to kdelibs.
To get an automake-ready qttestlib, unpack http://kdab.net/~dfaure/qttestlib.diff.bz2
in the toplevel of kdelibs.

OK with everyone?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.diff
Type: text/x-diff
Size: 4205 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050903/8aafc51c/attachment.diff>