If the deployment does not support IPv6, we use the following convention
to skip the tests at class level.
https://github.com/openstack/tempest/blob/master/tempest/api/network/base.py#L65
Regards,
--Sridhar.
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 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 <[email protected]
<mailto:[email protected]>> 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" <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
