openstack/deb-networking-odl
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 e4fccd1b9c
commit 1b090e5365
1 changed files with 35 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
TESTING
View File

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