On 2015-04-27 17:07:56 -0400 (-0400), Ronald Bradford wrote:
[...]
> Specifically, the following two code snippets have become SOP (Standard
> Operating Procedure) jumping around VMs and projects and I suspect if you
> are a developer of this project, something you are very familiar with.
[...]
> python tools/install_venv.py
> source .venv/bin/activate
>
> ./run_tests.sh
[...]
Not in my experience--common wisdom for the ~2.5 years I've been
involved has been to use tox. It's how we run these tests in gate
jobs, so if a developer is running in a different way they're likely
to encounter all sorts of inconsistencies between their local
results and what the CI eventually reports for a proposed change.
> it not longer exists in this project.
[...]
I consider it an unfortunate oversight that those files weren't
deleted a very, very long time ago.
> So I've solved how to run tests the new way, took longer to write
> this email. Still none the wiser how to run my code in a developer
> virtual environment.
When you use tox, it creates a virtualenv for each testenv in the
envlist from the tox.ini in the repo. You can find these virtualenvs
in the .tox directory after it runs, and can activate and update
them as needed. The documentation for tox is also quite
comprehensive (and linked from the wiki article you were quoting):
http://testrun.org/tox/
Or, you can activate the env and run testr manually (for projects
using it, which is most of them now) as mentioned in the "Writing
Tests for testr" wiki article for testr you linked in your message:
https://wiki.openstack.org/wiki/Testr#Writing_Tests_for_testr
--
Jeremy Stanley
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
