A test suite for dcop

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


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

Revert my hack for a<b<c>>. Better have a compile-time warning than a 
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).

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 

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

Luis Pedro Coelho

check out my game of hearts for the KDE at


More information about the kde-core-devel mailing list