diff --git a/.zuul.yaml b/.zuul.yaml index e707349419..45f19c2ce6 100644 --- a/.zuul.yaml +++ b/.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: diff --git a/doc/source/contributor/development.environment.rst b/doc/source/contributor/development.environment.rst index c3dfec6fb5..8d12a74a3c 100644 --- a/doc/source/contributor/development.environment.rst +++ b/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:: - 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 + $ tox -e venv -- 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 diff --git a/doc/source/contributor/unit_tests.rst b/doc/source/contributor/unit_tests.rst index 7d4052d039..6c1c8090aa 100644 --- a/doc/source/contributor/unit_tests.rst +++ b/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 + 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 `_. - ./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 ------- diff --git a/manila/testing/README.rst b/manila/testing/README.rst index e7142d734b..9d43cf4c46 100644 --- a/manila/testing/README.rst +++ b/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 ---------------------- diff --git a/tools/enable-pre-commit-hook.sh b/tools/enable-pre-commit-hook.sh index 14f47459f5..af0bb4a590 100755 --- a/tools/enable-pre-commit-hook.sh +++ b/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 - diff --git a/tox.ini b/tox.ini index 4da437402b..5a620dc4ee 100644 --- a/tox.ini +++ b/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