incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "scott comer (sccomer)" <>
Subject Re: interoperability testing... [again]
Date Fri, 09 Jan 2009 20:46:57 GMT
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:
> 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
> <
> g+Framework> 
> please review and comment.
> thanks,
> scott out

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message