[RFC] KUnitTest library

David Faure faure at kde.org
Fri Apr 8 14:03:45 BST 2005


On Friday 08 April 2005 14:10, Zack Rusin wrote:
> On Friday 08 April 2005 08:03, David Faure wrote:
> > On Friday 08 April 2005 13:05, Jeroen Wijnhout wrote:
> > > Well, there are some (although perhaps you just don't care about
> > > those): * code sharing
> > > * you automatically benefit from improvements in the library
> > > * you don't have to edit the kunittest.cpp file
> >
> > And the main one IMHO:
> > * ease of use, i.e. having very little code to write when adding a
> > new test. It should be as easy as: adding a method to an existing
> > test object (and it gets autodetected via QObject's slots mechanism)
> > or adding a file with a new test object (and adding it to
> > Makefile.am).
> 
> I'm surprised that geiseri hasn't yet commented on this thread. We 
> talked quite a bit about unit testing and validation testing.
> 
> I thought about QObject's introspection but at the end decided that I'd 
> prefer if the core of the lib didn't depend on anything. Furthermore 
> one of my biggest pet peeves is having to keep header/source in sync.

Contradictory statements IMHO :)
If you use QObject's introspection then you only have two places where to add
slotTestForFooBar() : the .cpp and the .h. Without the introspection you have
three places where to add it (.cpp, .h, and registering it somewhere).

IMHO something like kdebase/kioslave/trash/testrash.*, as a dlopened module,
and using slot introspection to discover all the test methods, would be fine.
After all this is about testing Qt/KDE code...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list