Dne 3.8.2017 v 17:52 Francesco napsal(a):
> Hello guys,
> 
> At the moment I am working on an application for testing embedded
> devices(mainly single board computers). As a testing suite, we are
> using avocado.
> 
> The aim of our project is to develop something that does not require a
> huge experience in python in order to being able to write a test.
> Most of the tests we need to perform should run both locally and
> through either serial or ssh and consist in a sequential execution of
> commands and output processing.
> To accomplish this, we were thinking to write wrappers around the
> Paramiko library and PySerial.
> 
> Our goal would be to write and execute the tests in a way similar to
> the example given for the process.run at page 17 of the documentation
> in pdf for Avocado 0.52. This means that the whole log of the
> operations should be done by the wrappers and not inside the Test
> class.
> 
> In summary, here is the example:
> avocado.fail_on(process.CmdError)
> def test(self):
> process.run("first cmd")
> process.run("second cmd")
> process.run("third cmd")
> 
> I was wondering if any of you has already worked on something similar
> or has some advice that may be helpful to me.
> 
> Thank you and best regards.
> 
> Frank.
> 

Hello Francesco,

let's clarify one thing first and then we can get to details. You claim you 
want to run tests either locally, or via serial console, but later you describe 
you just want to execute some parts of the test remotely, while executing the 
main test body locally, so which is your case? The difference is that:

1. running tests remotely - is supported by Avocado via `--remote*`, requires 
Avocado to be installed on the remote machine and the copy of the test 
available on the target machine. The main body of the test, sysinfo collection 
and basically everything runs there and is copied after the test is executed. 
This won't work on machines where running avocado-vt is impossible (eg. small 
device with not enough memory, or without support for python)

2. running tests locally, but some parts remotely - this is basically up to 
test writer and we do have some utils to help with that mainly because we were 
historically focused on virt testing which requires interacting with multiple 
machines via ssh or serial console. The main difference is that the main test 
body as well as sysinfo collection is run on the main host machine. On the 
other hand you don't need any deps on the target machine(s), they don't even 
need python.

From your description I assume it's the (2) option. I'd recommend tweaking the 
`/etc/avocado/sysinfo/commands` to always store some info about the target 
device, which will be useful when looking at the results later.

As for writing tests you can either use `aexpect` to initialize ssh/nc/socat 
connection to the target machine/device and interact with it. It can either be 
a basic `aexpect.Expect` instance, or if your device behaves (at least a bit 
like) shell, I'd recommend looking at `avocado.ShellSession`. You might need to 
supply custom `prompt` regexp as the default is `Linux` one and then it'll 
allow you many great features. You can see the details by running `python -c 
"import aexpect; help(aexpect.ShellSession)"`.

Then you can write tests like this:

```
def test(self):
    remote_cmd = self.params.get("remote_cmd")
    if remote_cmd:
        session = aexpect.ShellSession(remote_cmd, ...)
    else:
        session = aexpect.ShellSession("/bin/sh")
    session.cmd("true")
    session.sendline("dd if=/dev/zero of=/dev/null")
    session.sendcontrol("c")
    session.read_up_to_prompt()
    ...
```

Another approach would be to implement process.run-like object to interact with 
your machine/device. Example can be seen in 
`optional_plugins/runner_remote/avocado_runner_remote/__init__.py`, search for 
`class Remote(` and that is one implementation to interact with an ssh-like 
machine. Instance of such object can be passed to some of the `avocado.utils` 
libraries to get the functionality on the remote machine. Anyway I think the 
`aexpect` fits your needs, eventually you can inherit form it and add some 
convenient methods tailored to your needs.

Kind regards,
Lukáš

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to