Re: [Tsp-devel] A test campaign manager for dtest

[Eric NOULARD]

Le Mon, 21 Apr 2008 21:58:18 +0200,
Frederik Deweerdt <address@hidden> a écrit :

> On Sun, Apr 20, 2008 at 02:26:49PM +0200, Eric Noulard wrote:
> [...] 
> Just finished reading the research paper :).

More to come stay tuned :=)

> > Practically TAP only gives us vision of the "ok" steps,
> > I want to be able to trace ALL steps: ok, barrier, expect,
> > send, .... As an example I may want to define something like an
> > "observer step" which may gives me [non-intrusively] state
> > values/counters from a running DTester,
> > using these values I may implement an ok step in order to validate
> > the range of the values.
> Ok, I see. Didier seems to prefer a more versatile interface too.
> Just for arguments's sake, couldn't that be run like this:
> 
>     Client  -------------- Server
>          \                /  \------ Invariant observer
>          TAP            TAP           |
>            \->  DTestMaster  <---TAP--/
> 
> Even though what the observer observes is more than simple Ok/Nok
> steps. The answer to "did we perform y before x" is still Ok/Nok.
> I've got no strong feelings to keep TAP, 

I'm basically OK with TAP output as a "default" behaviour.
In order to keep it simple I will add a TraceHandler 
and a TraceManager to DTest with a "relatively open" API
which may handle "every kind of steps".
This is easy to do in python since we may pass "callable"
to a function and dynamically inspect its prototype.
(which is the task currently done with the stepmethod in 
 DTester::addRunStep(self, stepmethod,*args, **kwargs)
 method)

TAPTraceHandler will inherit from TraceHandler (which does
basically nothing beside defining the appropriate API 
callable by TraceManager).

TAPTraceHandler will only handle "ok" steps and ignore 
other steps which is the inherited behaviour.

> I just want to make sure that we're not over engineering here.

I don't think the scheme is over engineered since you won't
see the "over-engineered API" if you dont wan't to.

I'll try a first implementation of TraceManager, TraceHandler and
TAPTraceHandler in a day or 2.

 
--
Erk