acf0209b28
Interacting with a long-running asynchronous process requires the use of non-blocking io. This change adds a helper class that can launch a long-running process and read stdout and stderr in a non-blocking fashion via eventlet. This functionality is intended to support monitoring ovsdb via a long-running and root-privileged invocation of ovsdb-client. The complexity of the system interaction in this patch suggested the addition of a functional test that validated actual behaviour. The test was added under the neutron/tests/functional path which is now included in the testr search path. Partial-Bug: #1177973 Change-Id: I9969e556acecf7a9e77d873371cc2ec2647be011
65 lines
2.2 KiB
Plaintext
65 lines
2.2 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.
|
|
|
|
The functional tests are intended to validate actual system
|
|
interaction. Mocks should be used sparingly, if at all. Care
|
|
should be taken to ensure that existing system resources are not
|
|
modified and that resources created in tests are properly cleaned
|
|
up.
|
|
|
|
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
|
|
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 and functional tests.
|
|
|
|
To get a grasp of the areas where 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 tests for that feature or code area. Ideally any bugs
|
|
fixes that are submitted also have tests to prove that they stay
|
|
fixed! In addition, before proposing for merge, all of the
|
|
current tests should be passing.
|
|
|