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