Remove run_tests.sh

It is deprecated in favor of tox.

Closes-Bug: #1790470
Change-Id: If3b6a274dab0d035b9666b3b9876604cefbc2877

.zuul.yaml

@@ -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:

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``
+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.
 
@@ -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
+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
-``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
 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
+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

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/
+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
 -------------------------
-
 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
+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
 -------

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
+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
 ----------------------

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
-

tox.ini

@@ -56,8 +56,7 @@ commands =
          devstack/upgrade/shutdown.sh \
          devstack/upgrade/upgrade.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_logging.sh {toxinidir}/manila