Browse Source

Remove run_tests.sh

It is deprecated in favor of tox.

Closes-Bug: #1790470
Change-Id: If3b6a274dab0d035b9666b3b9876604cefbc2877
(cherry picked from commit 772a64a871)
(cherry picked from commit ec8c500f17)
changes/84/610984/1
Tom Barron 3 years ago
parent
commit
66105f93e3
  1. 4
      .zuul.yaml
  2. 55
      doc/source/contributor/development.environment.rst
  3. 123
      doc/source/contributor/unit_tests.rst
  4. 17
      manila/testing/README.rst
  5. 3
      tools/enable-pre-commit-hook.sh
  6. 3
      tox.ini

4
.zuul.yaml

@ -70,7 +70,6 @@
- ^manila/hacking/.*$
- ^manila/tests/.*$
- ^releasenotes/.*$
- ^run_tests.sh$
- ^setup.cfg$
- ^tools/.*$
- ^tox.ini$
@ -92,7 +91,6 @@
- ^manila/hacking/.*$
- ^manila/tests/.*$
- ^releasenotes/.*$
- ^run_tests.sh$
- ^setup.cfg$
- ^tools/.*$
- ^tox.ini$
@ -391,7 +389,6 @@
- ^manila/hacking/.*$
- ^manila/tests/.*$
- ^releasenotes/.*$
- ^run_tests.sh$
- ^tools/.*$
- ^tox.ini$
required-projects:
@ -414,7 +411,6 @@
- ^manila/hacking/.*$
- ^manila/tests/.*$
- ^releasenotes/.*$
- ^run_tests.sh$
- ^tools/.*$
- ^tox.ini$
required-projects:

55
doc/source/contributor/development.environment.rst

@ -121,15 +121,21 @@ Grab the code::
Running unit tests
------------------
The unit tests will run by default inside a virtualenv in the ``.venv``
directory. Run the unit tests by doing::
The preferred way to run the unit tests is using ``tox``. Tox executes tests in
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
environment (hit "y")::
Run the unit tests with::
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.
@ -138,38 +144,39 @@ See :doc:`unit_tests` for more details.
Manually installing and using the virtualenv
--------------------------------------------
You can manually install the virtual environment instead of having
``run_tests.sh`` do it for you::
You can also manually install the virtual environment::
tox -epy27 --notest
python tools/install_venv.py
or::
tox -epy36 --notest
This will install all of the Python packages listed in the
``requirements.txt`` file into your virtualenv. There will also be some
additional packages (pip, distribute, greenlet) that are installed
by the ``tools/install_venv.py`` file into the virtualenv.
``requirements.txt`` file into your virtualenv.
To activate the Manila virtualenv you can run::
$ source .tox/py27/bin/activate
If all goes well, you should get a message something like this::
or::
Manila development environment setup is complete.
$ source .tox/py36/bin/activate
To activate the manila virtualenv for the extent of your current shell session
you can run::
To exit your virtualenv, just type::
$ source .venv/bin/activate
$ deactivate
Or, if you prefer, you can run commands in the virtualenv on a case by case
basis by running::
$ tools/with_venv.sh <your command>
$ tox -e venv -- <your command>
Contributing Your Work
----------------------
Once your work is complete you may wish to contribute it to the project. Add
your name and email address to the ``Authors`` file, and also to the ``.mailmap``
file if you use multiple email addresses. Your contributions can not be merged
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_.
Once your work is complete you may wish to contribute it to the
project. 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

123
doc/source/contributor/unit_tests.rst

@ -8,128 +8,51 @@ Jenkins server if the change causes unit test failures.
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/
.. _pep8: https://github.com/jcrocholl/pep8
This will create a virtual environment, load all the packages from
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
flags by doing::
tox -e py27
run_tests.sh -h
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
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.
Running a subset of tests
-------------------------
Instead of running all tests, you can specify an individual directory, file,
class, or method that contains test code.
To run the tests in the ``manila/tests/scheduler`` directory::
./run_tests.sh scheduler
To run the tests in the ``manila/tests/test_libvirt.py`` file::
./run_tests.sh test_libvirt
To run the tests in the `HostStateTestCase` class in
``manila/tests/test_libvirt.py``::
./run_tests.sh test_libvirt:HostStateTestCase
To run the `ToPrimitiveTestCase.test_dict` test method in
``manila/tests/test_utils.py``::
./run_tests.sh test_utils:ToPrimitiveTestCase.test_dict
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.
tox -epy27 -- manila.tests.scheduler
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::
To run the tests in the `ShareManagerTestCase` class in
``manila/tests/share/test_manager.py``::
-s, --no-site packages
tox -epy27 -- manila.tests.share.test_manager.ShareManagerTestCase
If you do not wish to use a virtualenv at all, use the flag::
To run the `ShareManagerTestCase::test_share_manager_instance` test method in
``manila/tests/share/test_manager.py``::
-N, --no-virtual-env
tox -epy27 -- manila.tests.share.test_manager.ShareManagerTestCase.test_share_manager_instance
Database
--------
For more information on these options and details about stestr, please see the
`stestr documentation <http://stestr.readthedocs.io/en/latest/MANUAL.html>`_.
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::
Database Setup
--------------
-n, --no-recreate-db
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.
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
-------

17
manila/testing/README.rst

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

3
tools/enable-pre-commit-hook.sh

@ -17,7 +17,7 @@
PRE_COMMIT_SCRIPT=.git/hooks/pre-commit
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
if [ -w $PRE_COMMIT_SCRIPT -a -x $PRE_COMMIT_SCRIPT ]; then
@ -39,4 +39,3 @@ if [ ! -d ".git" ]; then
else
make_hook
fi

3
tox.ini

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

Loading…
Cancel
Save