Merge "Remove unit tests about run_test"

doc/source/contributor/unit_tests.rst

@@ -41,105 +41,6 @@ Or all tests in the test_volumes.py file::
 For more information on these options and how to run tests, please see the
 `ostestr documentation <https://docs.openstack.org/os-testr/latest/>`_.
 
-Run tests wrapper script
-------------------------
-
-In addition you can also use the wrapper script run_tests.sh by simply
-executing::
-
-    ./run_tests.sh
-
-This script is a wrapper around the testr testrunner and the flake8 checker.
-Note that there has been talk around deprecating this wrapper and this method of
-testing, it's currently available still but it may be good to get used to using
-tox or even ostestr directly.
-
-Documentation is left in place for those that still use it.
-
-Flags
------
-
-The ``run_tests.sh`` script supports several flags. You can view a list of
-flags by doing::
-
-    run_tests.sh -h
-
-This will show the following help information::
-    Usage: ./run_tests.sh [OPTION]...
-    Run cinderclient'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.
-      -f, --force                 Force a clean re-build of the virtual environment. Useful when dependencies have been added.
-      -u, --update                Update the virtual environment with any newer package versions
-      -p, --pep8                  Just run PEP8 and HACKING compliance check
-      -P, --no-pep8               Don't run static code checks
-      -c, --coverage              Generate coverage report
-      -d, --debug                 Run tests with testtools instead of testr. This allows you to use the debugger.
-      -h, --help                  Print this usage message
-      --hide-elapsed              Don't print the elapsed time for each test along with slow test list
-      --virtual-env-path <path>   Location of the virtualenv directory
-                                   Default: $(pwd)
-      --virtual-env-name <name>   Name of the virtualenv directory
-                                   Default: .venv
-      --tools-path <dir>          Location of the tools directory
-                                   Default: $(pwd)
-
-    Note: with no options specified, the script will try to run the tests in a virtual environment,
-          If no virtualenv is found, the script will ask if you would like to create one.  If you
-          prefer to run tests NOT in a virtual environment, simply pass the -N option.
-
-Because ``run_tests.sh`` is a wrapper around testr, it also accepts the same
-flags as testr. See the documentation for details about these additional flags:
-`ostestr documentation <https://docs.openstack.org/os-testr/latest/>`_.
-
-.. _nose options documentation: http://readthedocs.org/docs/nose/en/latest/usage.html#options
-
-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.
-(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
-
 Gotchas
 -------