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

[Eric Noulard]

2007/5/23, Frederik Deweerdt <address@hidden>:
> [...]
> > 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.
> Hm, this makes me wonder if they should really be subclasses. Shouldn't
> the local and ssh be seen as transports, not testers?  We would use
> dtest.DTester("Tester1", dtest.SSHTransport) at init time.

Yes it is a good approach.
The fact is it wasn't as clear as it is now but you are
perfectly  right.
The trouble is what service do you need for a "transport"?

"good" transport candidate are (from my point of view):

- ssh
- telnet
- local mean

for a "fully" functionnal "transport" for dtest I would need:

1) Some kind of pseudo-terminal which makes
   stdout/stdin/stderr connection to a process to be handled
   properly. With the ability to send some control code
   (Ctrl-C for example) and the ability to have "unbuffered"
   stdout/stderr in order to be able to handle waitFromCommand
   without trouble.

   (I may use pexpect for "local" process handling
    and you may read the Pexpect FAQ concerning
    PIPE and pty
    http://pexpect.sourceforge.net/#faq)

2) file copy (local-->remote), (remote-->local)

So I would either build a

DTester(name,transport,filetransfer)
or
DTester(name,sessionHandler)

The fact is SSH handles both 1) (SSH) and 2) (SFTP)
local mean may use 1) some pty handling 2) python file lib
telnet may handle 1) but I may need ftp for 2).

so ..

> With a tester being
> class Tester:
>         def __init__(name, transport)
>         def ok()
>         def barrier()

Yes. but I think we must keep high-level
runCommand()
expectCommand()
waitCommandTermination()

within DTester

and have lower level API for
Transport/FileTransfer.

I am wondering how to separate the API at the "good" level.

> > 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.
> Good idea, this would be a kind of "set environement" framework? (eg
> environment variables, UIDs)

Not exactly. I think that environment and UID should be set-up by:

1) for environnement var:
runCommand(command,environ)
or in two steps
setEnviron(environ)
then
runCommand(command)

2) for UID it is the responsibility of the "Transport" discussed before.

I was thinking of sending/receiving files between the machine
running "DTestMaster" and those running the DTesters.
The send/receive file need is twofold.

As an example, if you runCommand("tsp_ascii_writer")
on a remote host you need:

1) the tsp_ascii_writer executable to be on the remote host
   (it may not be installed)

2) may be an input file is to be used by you test executable.
    A configuration file "my_config.dat" for example if you rrun
    tsp_ascii_writer -x my_config.dat -u rpc://xxxxxxxxx -o result.csv

3) may be your remotely running command is producing
   output elsewhere than stdout, i.e. in an output file.

on your DTestMaster machine you may have ALL the files you need
(binaries executable, config files etc...)
such that your DTester for ascii_writer may:

a) send the appropriate tsp_ascii_writer binary(ies) to the remote host
   send the my_config.dat file to the remote location too

b) run the appropriate command line:
     tsp_ascii_writer -x my_config.dat -u rpc://xxxxxxxxx -o result.csv

c) retrieve the "result.csv" file from the remote host
   for an eventual comparison with a reference file on DTestMaster machine.

This way for each DTester not only you have stdin/stdout/stderr connection
but you must be able to send/receive file.

I may release a "usable" dtest without the file transfer feature because it
may be already useful without it, but I would like the overall design
to be ready for the feature.

> >
> > I have a wealth of ideas coming :))
> Happy hacking :)

Yes I am [happy] :))
Not too much time this week but the following week will be better.

--
Erk