A test suite for dcop

Luis Pedro Coelho luis_pedro at netcabo.pt
Mon Mar 10 19:24:31 GMT 2003


Hi,

As dfaure says in his last commit to kdelibs/dcop/dcopidl/yacc.yy:

<quote>
Revert my hack for a<b<c>>. Better have a compile-time warning than a 
non-working
DCOP call (the type "d<e> " is not handled by dcop due to the trailing space 
it seems).
Someone who knows a bit more about dcop's type handling should look into this
(but if no compiler really breaks on a<b<c>> there isn't much point).
</quote>

Except that it wasn't a hack for a<b<c>>, it was a bugfix and dcop is very 
broken with respect to error handling. In the process of starting to fix it a 
bit, I got all Extreme Programmingish and create a little test suite for 
dcop. It is now more or less usable and dcop (still) fails on many of the 
tests.

( For those interested here is what I do: I get a few test cases and then use 
perl to generate code to run these test cases in 3 modes: "local": no dcop 
involved, just function calls, "shell": using "dcop TestApp ...." and 
"remote": I get another programm which connects through dcop to the first app 
and calls the functions through a stub. The results (return values + stdout 
printing) of these three modes. This tests "dcop", "dcopidl" and 
"dcopidl2cpp" and some kdecore functions. )


I was wondering what to do with the test suite? 
Should I just keep it to myself (in its current ugly state, I will not even 
post it :) or should I clean it up and commit (or submit it here). They 
should probably go under kdelibs/tests/dcop because they depend on kdecore 
and should be built (and run) last.

Regards,
-- 
Luis Pedro Coelho

check out my game of hearts for the KDE at

http://hearts.sf.net




More information about the kde-core-devel mailing list