Update TESTING file

Fixes bug 1040566

Change-Id: Iff7a97532e1a6012d9d5cafb82ad7babfb9fd080

diff --git a/TESTING b/TESTING
index 7c16f374f8bd684343c31ee4c947cfae97bbeba4..d084156f0d63114947979de510bfce64aa0e0994 100644 (file)
--- a/TESTING
+++ b/TESTING
@@ -3,54 +3,56 @@ Testing Quantum
 
 Overview
 
-    There are two types of tests in quantum: functional and unit.  Their
-    respective directories are located in the tests/ directory.
-
-    The functional tests are intended to be used when the service is running.
-    Their goal is to make sure the service is working end to end and also to
-    test any plugin for conformance and functionality.  Also note that the
-    functional tests expect quantum to be running on the local machine.  If it
-    isn't you will have to change the tests to point to your quuntum instance.
-
-    The unit tests can be run without the service running.  They are designed
-    to test the various pieces of the quantum tree to make sure any new
-    changes don't break existing functionality.
+    The unit tests are meant to cover as much code as possible and should
+    be executed without the service running. They are designed to test
+    the various pieces of the quantum tree to make sure any new changes
+    don't break existing functionality.
 
 Running tests
 
-    All tests can be run via the run_tests.sh script, which will allow you to
-    run them in the standard environment or create a virtual environment to
-    run them in.  All of the functional tests will fail if the service isn't
-    running.  One current TODO item is to be able to specify whether you want
-    to run the functional or unit tests via run_tests.sh.
+    There are two mechanisms for running tests: run_tests.sh and tox.
+    Before submitting a patch for review you should always ensure all unit
+    test pass; a tox run is triggered by the jenkins gate executed on gerrit
+    for each patch pushed for review.
 
-    After running all of the tests, run_test.sh will report any pep8 errors
-    found in the tree.
+    With both mechanisms you can either run the tests in the standard
+    environment or create a virtual environment to run them in.
+
+    By default after running all of the tests, any pep8 errors
+    found in the tree will be reported.
 
 Running individual tests
 
-    Individual tests can be run using run_tests.py, you just need to pass
+    For running individual test modules or cases, you just need to pass
     the dot-separated path to the module you want as an argument to it.
-    For example, the following would run only the APITestV11 tests from
-    quantum/tests/unit/test_api.py:
 
-      $ ./run_tests.sh quantum.tests.unit.test_api:APITestV11
+    For executing a specific test case, specify the name of the test case
+    class separating it from the module path with a colon.
+
+    For example, the following would run only the JSONV2TestCase tests from
+    quantum/tests/unit/test_api_v2.py:
+
+      $ ./run_tests.sh quantum.tests.unit.test_api_v2:JSONV2TestCase
+
+    or
+
+      $ ./tox quantum.tests.unit.test_api_v2:JSONV2TestCase
 
 Adding more tests
 
-    Quantum is a pretty new code base at this point and there is plenty of
-    areas that need tests.  The current blueprint and branch for adding tests
-    is located at:
-    https://code.launchpad.net/~netstack/quantum/quantum-unit-tests
+    Quantum has a fast growing code base and there is plenty of areas that
+    need to be covered by unit tests.
+
+    To get a grasp of the areas where unit tests are needed, you can check
+    current coverage by running:
 
-    Also, there is a wiki page tracking the status of the test effort:
-    http://wiki.openstack.org/QuantumUnitTestStatus
+    $ ./run_tests.sh -c
 
 Development process
 
     It is expected that any new changes that are proposed for merge come with
-    unit tests for that feature or code area.  Ideally any bugs fixes that are
-    submitted also have unit tests to prove that they stay fixed! :)  In
-    addition, before proposing for merge, all of the current unit tests should
-    be passing.
+    unit tests for that feature or code area. Ideally any bugs fixes that are
+    submitted also have unit tests to prove that they stay fixed!
+    In addition, before proposing for merge, all of the current unit tests
+    should be passing.