tuskar-ui/docs/source/testing.rst
Gabriel Hurley 9742842795 Re-architects the OpenStack Dashboard for modularity and extensibility.
Implements blueprint extensible-architecture.
Implements blueprint improve-dev-documentation.
Implements blueprint gettext-everywhere.
Implements blueprint sphinx-docs.

Complete re-architecture of the dashboard to transform it from a standalone django-openstack app to a Horizon framework for building dashboards. See the docs for more information.

Incidentally fixes the following bugs:

Fixes bug 845868 -- no PEP8 violations.
Fixes bug 766096 -- the dashboard can now be installed at any arbitrary URL.
Fixes bug 879111 -- tenant id is now controlled solely by the tenant switcher, not the url (which was disregarded anyway)
Fixes bug 794754 -- output of venv installation is considerably reduced.

Due to the scale and scope of this patch I recommend reviewing it on github: https://github.com/gabrielhurley/horizon/tree/extensible_architecture

Change-Id: I8e63f7ea235f904247df40c33cb66338d973df9e
2011-11-07 12:59:21 -08:00

2.2 KiB

Testing Horizon

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.sh
ref/run_tests

Full reference for the run_tests.sh script.

How to write good tests

Horizon uses Django's unit test machinery (which extends Python's unittest2 library) as the core of it's test suite. As such, all tests for the Python code should be written as unit tests. No doctests please.

A few pointers for writing good tests:

  • Write tests as you go--If you save them to the end you'll write less of them and they'll often miss large chunks of code.
  • Keep it as simple as possible--Make sure each test tests one thing and tests it thoroughly.
  • Think about all the possible inputs your code could have--It's usually the edge cases that end up revealing bugs.
  • Use coverage.py to find out what code is not being tested.

In general new code without unit tests will not be accepted, and every bugfix must include a regression test.