x/vmware-nsx
Code Issues Proposed changes

Update TESTING file

Browse Source 
Fixes bug 1040566

Change-Id: Iff7a97532e1a6012d9d5cafb82ad7babfb9fd080
This commit is contained in:
Salvatore Orlando 2012-08-22 22:17:54 -07:00
parent 209efaa473
commit 3f5f3458a5
1 changed files with 35 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
TESTING
View File

@ -3,54 +3,56 @@ Testing Quantum
Overview Overview
There are two types of tests in quantum: functional and unit. Their The unit tests are meant to cover as much code as possible and should
respective directories are located in the tests/ directory. be executed without the service running. They are designed to test
the various pieces of the quantum tree to make sure any new changes
The functional tests are intended to be used when the service is running. don't break existing functionality.
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.
Running tests Running tests
All tests can be run via the run_tests.sh script, which will allow you to There are two mechanisms for running tests: run_tests.sh and tox.
run them in the standard environment or create a virtual environment to Before submitting a patch for review you should always ensure all unit
run them in. All of the functional tests will fail if the service isn't test pass; a tox run is triggered by the jenkins gate executed on gerrit
running. One current TODO item is to be able to specify whether you want for each patch pushed for review.
to run the functional or unit tests via run_tests.sh.
After running all of the tests, run_test.sh will report any pep8 errors With both mechanisms you can either run the tests in the standard
found in the tree. 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 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. 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 Adding more tests
Quantum is a pretty new code base at this point and there is plenty of Quantum has a fast growing code base and there is plenty of areas that
areas that need tests. The current blueprint and branch for adding tests need to be covered by unit tests.
is located at:
https://code.launchpad.net/~netstack/quantum/quantum-unit-tests
Also, there is a wiki page tracking the status of the test effort: To get a grasp of the areas where unit tests are needed, you can check
http://wiki.openstack.org/QuantumUnitTestStatus current coverage by running:
$ ./run_tests.sh -c
Development process Development process
It is expected that any new changes that are proposed for merge come with 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 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 submitted also have unit tests to prove that they stay fixed!
addition, before proposing for merge, all of the current unit tests should In addition, before proposing for merge, all of the current unit tests
be passing. should be passing.