Fwd: Re: Switching to QtTestLib for unit tests

[Brad Hards]

Resending. Broken kmail config the first time.

----------  Forwarded Message  ----------

Subject: Re: Switching to QtTestLib for unit tests
Date: Saturday 03 September 2005 20:50 pm
From: Brad Hards <bradh at frogmouth.net>
To: kde-core-devel at kde.org
Cc: David Faure <faure at kde.org>

I've just ported the (custom) unittests in the Qt4 bindings for Poppler, and
would also agree with changing to QtTestLib. I definitely plan to switch QCA
away from the (earlier) kunittest version, because the data-driven test
approach I have for QCA breaks on VC6.

On Saturday 03 September 2005 19:52 pm, David Faure wrote:
> Here's a list of other things that qttestlib provides over kunittest:
> * 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)

I think that these are the key technical advantages.

> * XML output (for GUIs)

Also handy for web-based reporting.

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

It won't work very well, yet. Failed checks don't set the exit value. I've
sent a one-line fix to Harald - still waiting on a response.
--- clean/qttestlib-2.0-opensource/src/qtestcase.cpp    2005-07-04
16:25:25.000000000 +0200
+++ qttestlib-2.0-opensource/src/qtestcase.cpp  2005-09-01 18:22:31.247838688
+0200
@@ -325,7 +325,7 @@

     QtTestLog::stopLogging();
     currentTestObject = 0;
-    return 0;
+    return QtTestResult::failCount();
 }

 void QtTest::fail(const char *statementStr, const char *file, int line)

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

This is at least as big an advantage as anything above. After all, we could
fix kunittest to do whatever qttestlib can do, but what would be the
advantage?

> If you wonder what switching would mean: see attached diff for
> ktempfiletest, including the full diff for importing qttestlib to kdelibs.

Do you really want to import qttestlib into kdelibs? QtTestLib shouldn't be a
requirement to use kdelibs, only to develop it. Would it make more sense to
import it into qt-copy? Perhaps we could try to convince the Trolls to ship
QtTestLib with Qt4.1....

Brad

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050904/234bc278/attachment.sig>