Re: [Tsp-devel] dtest: a distributed test framework

[Eric Noulard]

2007/5/22, Frederik Deweerdt <address@hidden>:
> >
> > Any comment are welcomed.
> >
> Well, first, it runs here :). It's really great, specially the
> expectFromCommand part. A few things, :

Cool :))

> - shouldn't the first argument of addRunStep be a real method instead
> of a string? That would may be simplify the code a bit and I don't see
> the added value of passing strings around.

In fact you may "ALREADY" pass an "unbounded method" :))
The following calls are valid and "equivalent":

stub.addRunStep(stub.__class__.ok,True,"TSP Stub and Stdout Starts")
or
stub.addRunStep(DTester.ok,True,"TSP Stub and Stdout Starts")
or
stub.addRunStep("ok",True,"TSP Stub and Stdout Starts")

but currently you may not use:
stub.addRunStep(stub.ok,True,"TSP Stub and Stdout Starts")

because my code does not handle bounded-method YET :))

In my first "draft" I would rather use:
stub.addRunStep(DTester.ok,True,"TSP Stub and Stdout Starts")

but using this I did not get the overriden method call I wish
in the  case where the stub is an instance of a SUBCLASS of DTester
and not a DTester.

I will handle this case soon.

More importantly "string" use case is shorter too write AND already
handle most specific method implementation.

> - The global timeout should be .. global :), we shouldn't pass it to each
> step, stub.globalTimeout=42 should be enough, and passing timeout=0 in
> case we want to disable it for a given step.

You are right and I did include a DTester specific timeout you may set with
stub.timeout = 42 it is currently not used, but you are right I will use
this "default" timeout value unless the user specified one in the runStep call.

This "DTester.timeout" is more like a "default timeout" for a specific DTester
there is another "global timeout" which belongs to
DTestMaster which is the timeout of the whole test sequence.

see DTestMaster.setGlobalTimeOut

> - AFAIK, the set/get way in python is as described here:
> http://tomayko.com/articles/2005/01/20/getters-setters-fuxors
> so there's no need for the  "def setCommand(self, command)" style setters
> in DTester.py

You are perfectly right, I will do this in a python way very soon.

> I realize that this was an early pre-release, but it looks great. I'll
> write a tester testing the output of autotest.py :)

Yep :=)

Besides the correction correspondign to your remark I will
add a sendFile/getFile on each DTester in order to have
"building blocks" for sending/getting files to/from the host machine
executing the DTester.

This way we may deploy precompiled binary or config files
for the remotely running command and get eventual result.
Using this we may do what you did in your initial DTest which is
to precompile python script for remote run (may be useful for
fine-grained library testing)

I will add in DTester a mean send the whole stderr/stdout output
to a stream handler during the test. This way we may store
thoses output to file or screen or whatever GUI renderer.

I have a wealth of ideas coming :))

Thank you for testing dtest :))
Stay tuned

--
Erk