Open Stack

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 method:
 @test.skip_because(bug="BUG_ID")

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?

Regards,
Om

On Wed, Nov 26, 2014 at 3:13 AM, Vineet Menon <mvineetmenon at gmail.com>
wrote:

> Hi,
> Thanjs for clearing that up... I had a hard time understanding the screws
> before I went with testr.
>
> Regards,
> Vineet
> 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 [1] a user can run tempest
>> tests
>> > 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
>> advantages
>> 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
>> because
>> I often mix unit tests and tempest runs and I like having separate venvs
>> for
>> both being created on demand.
>>
>> Calling testr directly is just what all of these tools are doing under the
>> covers, and it'll always be an option.
>>
>> One thing we're looking to do this cycle is to add a single entry point
>> for
>> running tempest which will hopefully clear up this confusion, and make the
>> 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
>> >
>> > [1]
>> http://docs.openstack.org/developer/tempest/overview.html#quickstart
>> >
>>
>> -Matt Treinish
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141128/9dc82338/attachment.html>