Remove run_tests.sh

It is deprecated in favor of tox.

Closes-Bug: #1790470
Change-Id: If3b6a274dab0d035b9666b3b9876604cefbc2877
This commit is contained in:
Tom Barron 2018-10-03 17:32:55 -04:00
parent f4eb29207e
commit 772a64a871
6 changed files with 67 additions and 138 deletions

View File

@ -67,7 +67,6 @@
- ^manila/hacking/.*$ - ^manila/hacking/.*$
- ^manila/tests/.*$ - ^manila/tests/.*$
- ^releasenotes/.*$ - ^releasenotes/.*$
- ^run_tests.sh$
- ^setup.cfg$ - ^setup.cfg$
- ^tools/.*$ - ^tools/.*$
- ^tox.ini$ - ^tox.ini$
@ -89,7 +88,6 @@
- ^manila/hacking/.*$ - ^manila/hacking/.*$
- ^manila/tests/.*$ - ^manila/tests/.*$
- ^releasenotes/.*$ - ^releasenotes/.*$
- ^run_tests.sh$
- ^setup.cfg$ - ^setup.cfg$
- ^tools/.*$ - ^tools/.*$
- ^tox.ini$ - ^tox.ini$
@ -390,7 +388,6 @@
- ^manila/hacking/.*$ - ^manila/hacking/.*$
- ^manila/tests/.*$ - ^manila/tests/.*$
- ^releasenotes/.*$ - ^releasenotes/.*$
- ^run_tests.sh$
- ^tools/.*$ - ^tools/.*$
- ^tox.ini$ - ^tox.ini$
required-projects: required-projects:
@ -413,7 +410,6 @@
- ^manila/hacking/.*$ - ^manila/hacking/.*$
- ^manila/tests/.*$ - ^manila/tests/.*$
- ^releasenotes/.*$ - ^releasenotes/.*$
- ^run_tests.sh$
- ^tools/.*$ - ^tools/.*$
- ^tox.ini$ - ^tox.ini$
required-projects: required-projects:

View File

@ -121,15 +121,21 @@ Grab the code::
Running unit tests Running unit tests
------------------ ------------------
The unit tests will run by default inside a virtualenv in the ``.venv`` The preferred way to run the unit tests is using ``tox``. Tox executes tests in
directory. Run the unit tests by doing:: isolated environment, by creating separate virtualenv and installing
dependencies from the ``requirements.txt`` and ``test-requirements.txt`` files,
so the only package you install is ``tox`` itself::
./run_tests.sh sudo pip install tox
The first time you run them, you will be asked if you want to create a virtual Run the unit tests with::
environment (hit "y")::
No virtual environment found...create one? (Y/n) tox -e py{python-version}
Example::
tox -epy27
tox -epy36
See :doc:`unit_tests` for more details. See :doc:`unit_tests` for more details.
@ -138,38 +144,39 @@ See :doc:`unit_tests` for more details.
Manually installing and using the virtualenv Manually installing and using the virtualenv
-------------------------------------------- --------------------------------------------
You can manually install the virtual environment instead of having You can also manually install the virtual environment::
``run_tests.sh`` do it for you::
python tools/install_venv.py tox -epy27 --notest
or::
tox -epy36 --notest
This will install all of the Python packages listed in the This will install all of the Python packages listed in the
``requirements.txt`` file into your virtualenv. There will also be some ``requirements.txt`` file into your virtualenv.
additional packages (pip, distribute, greenlet) that are installed
by the ``tools/install_venv.py`` file into the virtualenv.
If all goes well, you should get a message something like this:: To activate the Manila virtualenv you can run::
Manila development environment setup is complete. $ source .tox/py27/bin/activate
To activate the manila virtualenv for the extent of your current shell session or::
you can run::
$ source .venv/bin/activate $ source .tox/py36/bin/activate
To exit your virtualenv, just type::
$ deactivate
Or, if you prefer, you can run commands in the virtualenv on a case by case Or, if you prefer, you can run commands in the virtualenv on a case by case
basis by running:: basis by running::
$ tools/with_venv.sh <your command> $ tox -e venv -- <your command>
Contributing Your Work Contributing Your Work
---------------------- ----------------------
Once your work is complete you may wish to contribute it to the project. Add Once your work is complete you may wish to contribute it to the
your name and email address to the ``Authors`` file, and also to the ``.mailmap`` project. Manila uses the Gerrit code review system. For information on
file if you use multiple email addresses. Your contributions can not be merged how to submit your branch to Gerrit, see GerritWorkflow_.
into trunk unless you are listed in the Authors file. Manila uses the Gerrit
code review system. For information on how to submit your branch to Gerrit,
see GerritWorkflow_.
.. _GerritWorkflow: https://docs.openstack.org/infra/manual/developers.html#development-workflow .. _GerritWorkflow: https://docs.openstack.org/infra/manual/developers.html#development-workflow

View File

@ -8,128 +8,51 @@ Jenkins server if the change causes unit test failures.
Running the tests Running the tests
----------------- -----------------
Run the unit tests by doing::
./run_tests.sh To run all unit tests simply run::
This script is a wrapper around the `nose`_ testrunner and the `pep8`_ checker. tox
.. _nose: http://code.google.com/p/python-nose/ This will create a virtual environment, load all the packages from
.. _pep8: https://github.com/jcrocholl/pep8 test-requirements.txt and run all unit tests as well as run flake8 and hacking
checks against the code.
Flags You may run individual test targets, for example only py27 tests, by running::
-----
The ``run_tests.sh`` script supports several flags. You can view a list of tox -e py27
flags by doing::
run_tests.sh -h Note that you can inspect the tox.ini file to get more details on the available
options and what the test run does by default.
This will show the following help information::
Usage: ./run_tests.sh [OPTION]...
Run manila's test suite(s)
-V, --virtual-env Always use virtualenv. Install automatically if not present
-N, --no-virtual-env Don't use virtualenv. Run tests in local environment
-s, --no-site-packages Isolate the virtualenv from the global Python environment
-r, --recreate-db Recreate the test database (deprecated, as this is now the default).
-n, --no-recreate-db Don't recreate the test database.
-x, --stop Stop running tests after the first error or failure.
-f, --force Force a clean re-build of the virtual environment. Useful when dependencies have been added.
-p, --pep8 Just run pep8
-P, --no-pep8 Don't run pep8
-c, --coverage Generate coverage report
-h, --help Print this usage message
--hide-elapsed Don't print the elapsed time for each test along with slow test list
Because ``run_tests.sh`` is a wrapper around nose, it also accepts the same
flags as nosetests. See the `nose options documentation`_ for details about
these additional flags.
.. _nose options documentation: http://readthedocs.org/docs/nose/en/latest/usage.html#options
Running a subset of tests Running a subset of tests
------------------------- -------------------------
Instead of running all tests, you can specify an individual directory, file, Instead of running all tests, you can specify an individual directory, file,
class, or method that contains test code. class, or method that contains test code.
To run the tests in the ``manila/tests/scheduler`` directory:: To run the tests in the ``manila/tests/scheduler`` directory::
./run_tests.sh scheduler tox -epy27 -- manila.tests.scheduler
To run the tests in the ``manila/tests/test_libvirt.py`` file:: To run the tests in the `ShareManagerTestCase` class in
``manila/tests/share/test_manager.py``::
./run_tests.sh test_libvirt tox -epy27 -- manila.tests.share.test_manager.ShareManagerTestCase
To run the tests in the `HostStateTestCase` class in To run the `ShareManagerTestCase::test_share_manager_instance` test method in
``manila/tests/test_libvirt.py``:: ``manila/tests/share/test_manager.py``::
./run_tests.sh test_libvirt:HostStateTestCase tox -epy27 -- manila.tests.share.test_manager.ShareManagerTestCase.test_share_manager_instance
To run the `ToPrimitiveTestCase.test_dict` test method in For more information on these options and details about stestr, please see the
``manila/tests/test_utils.py``:: `stestr documentation <http://stestr.readthedocs.io/en/latest/MANUAL.html>`_.
./run_tests.sh test_utils:ToPrimitiveTestCase.test_dict Database Setup
--------------
Some unit tests will use a local database. You can use
``tools/test-setup.sh`` to set up your local system the same way as
it's setup in the CI environment.
Suppressing logging output when tests fail
------------------------------------------
By default, when one or more unit test fails, all of the data sent to the
logger during the failed tests will appear on standard output, which typically
consists of many lines of texts. The logging output can make it difficult to
identify which specific tests have failed, unless your terminal has a large
scrollback buffer or you have redirected output to a file.
You can suppress the logging output by calling ``run_tests.sh`` with the nose
flag::
--nologcapture
Virtualenv
----------
By default, the tests use the Python packages installed inside a
virtualenv [#f1]_. (This is equivalent to using the ``-V, --virtualenv`` flag).
If the virtualenv does not exist, it will be created the first time the tests are run.
If you wish to recreate the virtualenv, call ``run_tests.sh`` with the flag::
-f, --force
Recreating the virtualenv is useful if the package dependencies have changed
since the virtualenv was last created. If the ``requirements.txt`` or
``tools/install_venv.py`` files have changed, it's a good idea to recreate the
virtualenv.
By default, the unit tests will see both the packages in the virtualenv and
the packages that have been installed in the Python global environment. In
some cases, the packages in the Python global environment may cause a conflict
with the packages in the virtualenv. If this occurs, you can isolate the
virtualenv from the global environment by using the flag::
-s, --no-site packages
If you do not wish to use a virtualenv at all, use the flag::
-N, --no-virtual-env
Database
--------
Some of the unit tests make queries against an sqlite database [#f2]_. By
default, the test database (``tests.sqlite``) is deleted and recreated each
time ``run_tests.sh`` is invoked (This is equivalent to using the
``-r, --recreate-db`` flag). To reduce testing time if a database already
exists it can be reused by using the flag::
-n, --no-recreate-db
Reusing an existing database may cause tests to fail if the schema has
changed. If any files in the ``manila/db/sqlalchemy`` have changed, it's a good
idea to recreate the test database.
Gotchas Gotchas
------- -------

View File

@ -34,12 +34,17 @@ is overridden.
Running Tests Running Tests
------------- -------------
In the root of the Manila source code run the run_tests.sh script. This will The preferred way to run the unit tests is using ``tox``. Tox executes tests in
offer to create a virtual environment and populate it with dependencies. isolated environment, by creating separate virtualenv and installing
If you don't have dependencies installed that are needed for compiling Manila's dependencies from the ``requirements.txt`` and ``test-requirements.txt`` files,
direct dependencies, you'll have to use your operating system's method of so the only package you install is ``tox`` itself::
installing extra dependencies. To get help using this script execute it with
the -h parameter to get options `./run_tests.sh -h` sudo pip install tox
Run the unit tests by doing::
tox -e py3
tox -e py27
Tests and assertRaises Tests and assertRaises
---------------------- ----------------------

View File

@ -17,7 +17,7 @@
PRE_COMMIT_SCRIPT=.git/hooks/pre-commit PRE_COMMIT_SCRIPT=.git/hooks/pre-commit
make_hook() { make_hook() {
echo "exec ./run_tests.sh -N -p" >> $PRE_COMMIT_SCRIPT echo "exec tox -e fast8" >> $PRE_COMMIT_SCRIPT
chmod +x $PRE_COMMIT_SCRIPT chmod +x $PRE_COMMIT_SCRIPT
if [ -w $PRE_COMMIT_SCRIPT -a -x $PRE_COMMIT_SCRIPT ]; then if [ -w $PRE_COMMIT_SCRIPT -a -x $PRE_COMMIT_SCRIPT ]; then
@ -39,4 +39,3 @@ if [ ! -d ".git" ]; then
else else
make_hook make_hook
fi fi

View File

@ -56,8 +56,7 @@ commands =
devstack/upgrade/shutdown.sh \ devstack/upgrade/shutdown.sh \
devstack/upgrade/upgrade.sh \ devstack/upgrade/upgrade.sh \
tools/cover.sh \ tools/cover.sh \
tools/check_logging.sh \ tools/check_logging.sh
run_tests.sh
{toxinidir}/tools/check_exec.py {toxinidir}/manila {toxinidir}/tools/check_exec.py {toxinidir}/manila
{toxinidir}/tools/check_logging.sh {toxinidir}/manila {toxinidir}/tools/check_logging.sh {toxinidir}/manila