well, the interop testing framework is needed to be able to say with
confidence that all the
various operating modes and language binding combinations actually work.
this is done
now with expensive manual testing, when it is done at all. this was a
hot button with louis
and he wanted it also for cuae use.
i'd say, in general, testing is just about the highest priority thing
there is. plus, the code for
this is written, mostly, with some tweaking needed to accommodate any
suggestions here.
one thing i don't like is the xml is ugly. but a possible deployment
scenario is as an ant
task, in which case the xml is a given.
what i didn't discuss is parameter substitution, which can occur at each
level as you
progress down, and also parameter declarations with default values.
i'm trying to gauge if this is where we want to go or of anyone knows of
a worked
solution that we should look at.
scott out
J.D. Liau (jliau) wrote:
This framework definitely will help Etch developers down the road but I
see this as lower priority item compares to other near term enhancements
such as name service.
What kind of control can the framework have on the interface level? For
example, each run has different set of values for method parameters.
Extend <stdouttg> and <stderrtag> to support timestamp?
________________________________
From: Scott Comer (sccomer)
Sent: Friday, January 09, 2009 9:14 AM
To: [email protected]
Subject: rfc: interoperability testing... [again]
[sorry, i flubbed the link. -scott]
i've put a note up on the wiki about ideas for interoperability testing.
Interoperability Testing Framework
<http://cwiki.apache.org/confluence/display/ETCH/Interoperability+Testin
g+Framework>
please review and comment.
thanks,
scott out
