Remove run_tests.sh
It is deprecated in favor of tox. Closes-Bug: #1790470 Change-Id: If3b6a274dab0d035b9666b3b9876604cefbc2877
This commit is contained in:
Tom Barron
parent
f4eb29207e
commit
772a64a871
@ -67,7 +67,6 @@
|
||||
- ^manila/hacking/.*$
|
||||
- ^manila/tests/.*$
|
||||
- ^releasenotes/.*$
|
||||
- ^run_tests.sh$
|
||||
- ^setup.cfg$
|
||||
- ^tools/.*$
|
||||
- ^tox.ini$
|
||||
@ -89,7 +88,6 @@
|
||||
- ^manila/hacking/.*$
|
||||
- ^manila/tests/.*$
|
||||
- ^releasenotes/.*$
|
||||
- ^run_tests.sh$
|
||||
- ^setup.cfg$
|
||||
- ^tools/.*$
|
||||
- ^tox.ini$
|
||||
@ -390,7 +388,6 @@
|
||||
- ^manila/hacking/.*$
|
||||
- ^manila/tests/.*$
|
||||
- ^releasenotes/.*$
|
||||
- ^run_tests.sh$
|
||||
- ^tools/.*$
|
||||
- ^tox.ini$
|
||||
required-projects:
|
||||
@ -413,7 +410,6 @@
|
||||
- ^manila/hacking/.*$
|
||||
- ^manila/tests/.*$
|
||||
- ^releasenotes/.*$
|
||||
- ^run_tests.sh$
|
||||
- ^tools/.*$
|
||||
- ^tox.ini$
|
||||
required-projects:
|
||||
|
||||
@ -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::
|
||||
|
||||
python tools/install_venv.py
|
||||
tox -epy27 --notest
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
you can run::
|
||||
or::
|
||||
|
||||
$ 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
|
||||
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
|
||||
|
||||
@ -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
|
||||
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
|
||||
``manila/tests/test_libvirt.py``::
|
||||
To run the `ShareManagerTestCase::test_share_manager_instance` test method in
|
||||
``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
|
||||
``manila/tests/test_utils.py``::
|
||||
For more information on these options and details about stestr, please see the
|
||||
`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
|
||||
-------
|
||||
|
||||
@ -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
|
||||
----------------------
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user