[Kst] Test framework

George Staikos staikos at kde.org
Thu Nov 25 01:33:45 CET 2004


The test framework is roughly in place for math objects now, so I think we can 
proceed with writing them.  I started the histogram testcase (just picked one 
randomly), and already I am thinking I may have found some bugs, but let's 
see.......

Now, here's how the testcase system works.  Copy testtemplate.cpp to 
test<foo>.cpp and edit.  Change testtemplate in the KApplication constructor 
to test<foo> and add the appropriate include directives at the top.  Then 
fill in the doTests() function.

I added a few helper tools which you may or may not want to use - whatever 
seems best for your tests.  They work like this:

doTest(x):  Checks x to see if it is true or false.  If true, fall through.  
If false, declare the test run a failure and print a message to the screen 
with the line number in the testcase file that failed.
doTest(x, y): Same as above, but the contents of "y" (anything that 
QString::arg() likes) is also printed on failure.
testAssert(result, text): Same as above, except the line number of failure is 
not printed, only the contents of the QString "text".

I will be working on scripts and adding coverage support and automation next.  
These existing templates should be good enough to do testcases for:
KstHistogram
KstPSD and fftsg
KstVector
KstRVector
KstScalar
KstPlugin and family
KstVCurve
KstImage
Kstdefaultnames/vectordefaults
KstMatrix
KstPoint
KstEquation  (note: eparse, escan, and enode* already have testcases, so this 
one only needs KstEquation:: specific interface tests)


Coverage.  This is important.  Each and every method and function should be 
tested, but they also need to be tested in combination with eachother, and 
with the object in different states internally.  I will eventually have an 
automated coverage check in place, running weekly or more frequently, and 
reporting to the list.


Combination tests.  At some point we should also make even more complex tests 
where we combine various objects to make sure they interact properly.  I'm 
not sure what is needed yet, but this is quite far in the future as far as 
the scope of our testing needs go.


Collaboration.  I think it makes most sense to send a message to the list 
saying "I'm writing testcases for X" so that two people don't do the same 
one.  To get things started, I'm doing escan/eparse/enode*.  I am -not- doing 
histograms, but whoever does it can take over where I left off.


Any questions?

-- 
George Staikos
KDE Developer			http://www.kde.org/
Staikos Computing Services Inc.	http://www.staikos.net/



More information about the Kst mailing list