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 <mvineetme...@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" <mtrein...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev