[openstack-dev] [tempest] How to run tempest tests
om prakash pandey
pandeyop at gmail.com
Fri Nov 28 09:24:53 UTC 2014
I'm aware of using "skipException" for skipping tests at class level.
However, this involves putting it in every class to skip tests which are
I was looking for a way to control the tests I want to run through some
kind of a configuration file, the options to pass to test runner.
On Fri, Nov 28, 2014 at 2:02 PM, Sridhar Gaddam <sridhar.gaddam at enovance.com
> If the deployment does not support IPv6, we use the following convention
> to skip the tests at class level.
> On 11/28/2014 01:50 PM, om prakash pandey wrote:
> Hi Folks,
> I would like to know about the "best practices" followed for skipping
> tests not applicable for my environment.
> I know one of the ways is to use the below decorator over the test
> However, what if my deployment doesn't support VPNAAS and I want to skip
> those tests. Similarly, what if I want to skip the entire suite of
> sahara(data processing) tests.
> Are there any options in testr to customize running of tempest tests as
> per my environment/requirements?
> On Wed, Nov 26, 2014 at 3:13 AM, Vineet Menon <mvineetmenon at gmail.com>
>> Thanjs for clearing that up... I had a hard time understanding the screws
>> before I went with testr.
>> On 25 Nov 2014 17:46, "Matthew Treinish" <mtreinish at kortar.org> wrote:
>>> On Mon, Nov 24, 2014 at 10:49:27AM +0100, Angelo Matarazzo wrote:
>>> > Sorry for my previous message with wrong subject
>>> > Hi all,
>>> > By reading the tempest documentation page  a user can run tempest
>>> > by using whether testr or run_tempest.sh or tox.
>>> > What is the best practice?
>>> > run_tempest.sh has several options (e.g. ./run_tempest.sh -h) and it
>>> is my
>>> > preferred way, currently.
>>> > Any thought?
>>> So the options are there for different reasons and fit different
>>> purposes. The
>>> run_tempest.sh script exists mostly for legacy reasons as some people
>>> prefer to
>>> use it, and it predates the usage of tox in tempest. It also has some
>>> like that it can run without a venv and provides some other options.
>>> Tox is what we use for gating, and we keep most of job definitions for
>>> gating in
>>> the tox.ini file. If you're trying to reproduce a gate run locally using
>>> tox is
>>> what is recommended to use. Personally I use it to run everything just
>>> I often mix unit tests and tempest runs and I like having separate venvs
>>> both being created on demand.
>>> Calling testr directly is just what all of these tools are doing under
>>> covers, and it'll always be an option.
>>> One thing we're looking to do this cycle is to add a single entry point
>>> running tempest which will hopefully clear up this confusion, and make
>>> interface for interacting with tempest a bit nicer. When this work is
>>> done, the
>>> run_tempest.sh script will most likely disappear and tox will probably
>>> just be
>>> used for gating job definitions and just call the new entry-point
>>> instead of
>>> testr directly.
>>> > BR,
>>> > Angelo
>>> > 
>>> -Matt Treinish
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev