blob: a968ae50d5139f03f11ecf53098621ef8ebba080 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
..
Copyright 2011 OpenStack, LLC
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
===============
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
.. seealso::
:doc:`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.
|
