Update TESTING file
Fixes bug 1040566 Change-Id: Iff7a97532e1a6012d9d5cafb82ad7babfb9fd080
This commit is contained in:
parent
209efaa473
commit
3f5f3458a5
68
TESTING
68
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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user