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

[Vincent Matossian]

Interesting thread. A parallel/complementary approach might be to write an
Autotest plugin + auto test runner? it isn't as clean as porting existing
tests which would allow reviewing and cleaning things up but it does allow
folks to run their non-contributed autotest tests through Avocado in a
generic manner.

-
Vincent

On Mon, Jan 11, 2016 at 10:07 AM, Cleber Rosa <crosa at redhat.com> wrote:

>
>
> ----- 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
> >
>
> _______________________________________________
> Avocado-devel mailing list
> Avocado-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/avocado-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20160112/9c452657/attachment.htm>