From 1b090e5365952fdc63ddd185dfdf5a21f4f48b12 Mon Sep 17 00:00:00 2001 From: Salvatore Orlando Date: Wed, 22 Aug 2012 22:17:54 -0700 Subject: [PATCH] Update TESTING file Fixes bug 1040566 Change-Id: Iff7a97532e1a6012d9d5cafb82ad7babfb9fd080 --- TESTING | 68 +++++++++++++++++++++++++++++---------------------------- 1 file changed, 35 insertions(+), 33 deletions(-) diff --git a/TESTING b/TESTING index 7c16f374f..d084156f0 100644 --- 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. - Also, there is a wiki page tracking the status of the test effort: - http://wiki.openstack.org/QuantumUnitTestStatus + To get a grasp of the areas where unit tests are needed, you can check + current coverage by running: + + $ ./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.