[PyKDE] KDE XML GUI ActionLists

[Jim Bublitz]

On 24-Apr-03 Gordon Tyler wrote:
> On April 23, 2003 01:20 pm, Jim Bublitz wrote:
 
> How do you write unit tests for this sort of project?

For a few things (static methods that invoke a dialog with local
event loop, or variable-result system related calls like KService
stuff) I just write something to exercise the code and look at the
results manually, but there isn't a lot of that. For everything
else, I start from the assumption that sip generated code is
correct, or at least the errors will be apparent in example code, or
that I'll catch major sip errors as a side effect of other tests.

That leaves handwritten code to test - %MemberCode and
%MappedTypes. The basic framework is a simple KApplication (I need
a few widgets and most code requires a KApplication instance
anyway), with a "test" button. The unit tests (from the unittest
module framework) are connected to the button clicked () signal.
Interestingly, if I don't start the event loop, I get a lot of
random crashes, so the button is required. The tests run pass/fail
- about the same as doing 'make test' for Python (but shorter).

For %MemberCode, I call a method using fixed args and test the
return value(s) (many return tuples or lists). For %MappedTypes, I
try to find a method that utilizes the mapped type and do the same
thing. Mapped types are just C++ <-> Python conversion functions, so
if I can't find a suitable (ie codable in 4-5 lines) method, I just
write a test method, as for KActionList (in C++):

    KActionList testKActionList (KActionList)

and send it a Python list (or whatever) and test that I get the same
list back. The test function converts the Python list to a QPtrList
and then from QPtrList to a Python list and returns it. 

The errors I'm finding are things like failing to create a new
object in a conversion function, incorrect argument typing, missing
args, object reference treated as input-only when it's actually
an output or both. Because of that, I don't worry a lot about
corner cases, as failures are likely to be not-to-subtle. If I was 
doing a math lib, I'd approach it differently. I found one mapped
type where I'd missed a  C++ ";" and it still compiled (wrongly of
course) - first time I've seen that. Most bugs are in places not
very important to most people, but they're still bugs, and
eventually someone will want to use that code.

In a few cases, it's just too involved at the moment to create the
objects for a test or I haven't figured out exactly how KDE
works in those instances (eg DCOPObjRef in both cases), so I'm
leaving those until last - I'm probably a little over 2/3 done.

There's a second test program which just prints values instead of
doing 'asserts', and I use that for the stuff that isn't
automatable and to develop the automated tests (so I'm sure I
understand the inputs and outputs).

I'll probably include both test programs with the next release. 
The unit tests cover the most probable failure modes (ie, code I
write). Overall, I think it's a pretty good test strategy. 


Jim