aca739445e
* Moves all tests to use a single set of central test data and
Adds a nifty manager for it.
Implements blueprint unified-test-data.
* Cleans up API code and API tests so that we're not testing
code that has no custom logic, or wrapping objects unnecessarily.
Implements blueprint api-simplification.
* Adds lots of docs on testing. It's a good step towards
blueprint improve-dev-documentation.
* Improves API exception handling for duplicate objects and containers.
Fixes bug 930816.
Change-Id: I5526ccf5b38708885ea2d1f06b0d3483c58c4dad
1.3 KiB
Horizon's tests and you
How to run the tests
Because Horizon is composed of both the horizon app and
the openstack-dashboard reference project, there are in
fact two sets of unit tests. While they can be run individually without
problem, there is an easier way:
Included at the root of the repository is the
run_tests.sh script which invokes both sets of tests, and
optionally generates analyses on both components in the process. This
script is what what Jenkins uses to verify the stability of the project,
so you should make sure you run it and it passes before you submit any
pull requests/patches.
To run the tests:
$ ./run_tests.shref/run_tests-
Full reference for the
run_tests.shscript.
Writing tests
Horizon uses Django's unit test machinery (which extends Python's
unittest2 library) as the core of its test suite. As such,
all tests for the Python code should be written as unit tests. No
doctests please.
In general new code without unit tests will not be accepted, and every bugfix must include a regression test.
For a much more in-depth discussion of testing, see the testing topic
guide </topics/testing>.