ee3fe4e836
This change renames everything to Neutron while providing backwards compatible adjustments for Grizzly configuration files. implements blueprint: remove-use-of-quantum Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
59 lines
2.0 KiB
Plaintext
59 lines
2.0 KiB
Plaintext
Testing Neutron
|
|
=============================================================
|
|
|
|
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 neutron 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
|
|
neutron/tests/unit/test_api_v2.py:
|
|
|
|
$ ./run_tests.sh neutron.tests.unit.test_api_v2:JSONV2TestCase
|
|
|
|
or
|
|
|
|
$ ./tox neutron.tests.unit.test_api_v2:JSONV2TestCase
|
|
|
|
Adding more tests
|
|
|
|
Neutron 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.
|
|
|