Open Stack

What prevent us to make testr more tempest friendly ?
I did not find the how to contribute page.

I am not sure is adding nosetests features or features helping
developing tests with shared resources are welcome.

I do not see how the fixtures can help,
in the speed up perspective, if we cannot have faster parallel tempest,
with adding a feature for calling the setUpClass and tearDownclass on every setUp
 and tearDown.

What is your opinion about, adding a configuration option and some tricky
code for switching tempest to the above mode ?

We have 2 not independent test class AFAIK, they should be fixed anyway.

We have many possibilities to speed up tempest on single thread,
but non of the tricks can be stronger than an unlimited
 horizontal scalability.
Huge amount of raw force is stronger, than any single host optimization.

----- Original Message -----
From: "Matthew Treinish" <mtreinish at kortar.org>
To: openstack-qa at lists.openstack.org
Cc: openstack-dev at lists.openstack.org
Sent: Thursday, June 6, 2013 5:38:58 PM
Subject: [openstack-qa] Using Fixtures with Tempest


So I've started working on using fixtures with tempest, as a first step towards
making tempest more testr friendly. I've started experimenting with it by using
the images tests in tempest/api/images. (the glance api tests) The glance tests
are a small enough set and relatively self contained in tempest that it's a good
place to prototype this. I'm trying to figure out the best model for what should
be created and used in a fixture. But, I'm still new with the whole fixtures
model, so if anyone has any insight on the best way to organize things as
fixture that would be great.

Right now the image tests have a base image test class that contains a couple of
helper functions, a manager object(which contains all the client objects) and a
list of created images. This base class is inherited by an api version specific
test classes that just specify the client object and run a check in setUpClass()
to ensure that glance api supports that particular api version. These api
version specific classes are then inherited by all the image test classes split
by api version. It's probably also worth noting that two of these test classes
create a number of images in setUpClass() to use for the list operations being
tested in the individual test methods.

I was thinking that fixtures could be used a number of different ways in this
code, but I was leaning towards just having an images fixture that contained
the list of images as a starting point. This would still keep the same class
structure for the tests but move the resource tracking into a fixture. But,
I'm not sure this would be the most effective use of fixtures.

Does anyone have any ideas or insight into how fixtures should be used here?

Thanks,

Matt Treinish

_______________________________________________
openstack-qa mailing list
openstack-qa at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa