neutron/TESTING

59 lines
2.0 KiB
Plaintext

Testing Quantum
=============================================================
Overview
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
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.
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
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 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 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:
$ ./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.