[Avocado-devel] Port autotest client tests to avocado: next steps?

[Cleber Rosa]

----- Original Message -----
> From: "Amador Pahim" <apahim at redhat.com>
> To: avocado-devel at redhat.com
> Sent: Monday, January 11, 2016 3:12:00 PM
> Subject: [Avocado-devel] Port autotest client tests to avocado: next steps?
> 
> Hello,
> 
> In a first interaction trying to port autotest client tests to avocado,
> I could verify the port was quite simple for the tests I worked on
> (stress, compilebench, aiostress and bonnie). These 4 tests are already
> present in examples/tests/ directory.
> 

Very good indeed!

> There are currently 105 tests in avocado-client-tests and we should now
> discuss if/when(priority?) are we going to port them all and, if yes,
> some extra points should be discussed:
> 

I believe this is actually a task in itself: discard the tests that are
not useful in any way shape or form. Then, the remaining tests will be
part of a list of test that we *want* to have ported. Not necessarily
one person will do all that, and this is indeed a perfect example of first
time contributions to Avocado. Trello cards with "low hanging fruit" for
those could attract those first time contributors.

> - Many tests are just a matter of extract/configure/make a tarball and
> run the binary with proper arguments. Instead of writing one test per
> tarball, we could create a base test and vary only the yaml file
> containing the url to on-demand download the tarball and the arguments
> to be used with the resulting binary.
> 

I see the following tasks here:

1) Prototype a "TarballBuildAndRunTest" base class
2) Port a few tests that adhere to this initial base class implementation

The tests that were already ported are probably good candidates to be
"ported" yet again to this base class.

> - Either downloading the tarball during the test or keeping the tarball
> in the repository, should we create a separate repository to keep all
> those tests/tarballs?

3) Create a separate "avocado-tests" repo.
4) Implement the concept of "lazy download of resource files". A tarball
should be considered just that, a binary resource. If a resource URL is local,
assume it's in the test data dir. If the URL is remote (say http) then
check if it's already downloaded (checking a hash), if not downloaded download
it during test.
5) Define a naming convention for a YAML tree/keys that describe resource
files which may be used during tests.
6) Write a script (contrib or official) that goes over the YAML files and
checks/downloads the resource files.

Note that #3 doesn't depend on anything, but it only makes sense if we
decide to expand the set of ported tests (which I think we should).
Also, if Tasks 4, 5 and 6 are implemented, the idea of a separate repo
(#3) may loose a bit of its value, since the ported tests should be a
pretty small amount of Python code.

> 
> The hope is we can discuss/define the next steps regarding this matter.
> Could you share your thoughts?
> 
> Best,
> --
> apahim
> 
> _______________________________________________
> Avocado-devel mailing list
> Avocado-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/avocado-devel
>