You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by "scott comer (sccomer)" <sc...@cisco.com> on 2009/01/09 16:14:27 UTC
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+Testing+Framework>
please review and comment.
thanks,
scott out
Re: interoperability testing... [again]
Posted by James Dixson <di...@gmail.com>.
Scott.. if you have something written already then lets see it
working. I would rather get some experience with it before worrying
about migrating to some other test technology. Testing is an ongoing
challenge. I am interested certainly, but not as interested as I am in
other Etch enhancements like a name/discovery service.
On Fri, Jan 9, 2009 at 2:46 PM, scott comer (sccomer) <sc...@cisco.com> wrote:
> 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: etch-dev@incubator.apache.org
>> 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
>>
>>
>>
>>
>
Re: interoperability testing... [again]
Posted by "scott comer (sccomer)" <sc...@cisco.com>.
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: etch-dev@incubator.apache.org
> 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
>
>
>
>
RE: interoperability testing... [again]
Posted by "J.D. Liau (jliau)" <jl...@cisco.com>.
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: etch-dev@incubator.apache.org
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