File: HACKING.rst

package info (click to toggle)
senlin 6.0.0-1
  • links: PTS, VCS
  • area: main
  • in suites: buster
  • size: 6,872 kB
  • sloc: python: 66,932; sh: 588; makefile: 196
file content (57 lines) | stat: -rw-r--r-- 2,192 bytes parent folder | download | duplicates (2)
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
Senlin Style Commandments
=========================

- Step 1: Read the OpenStack Style Commandments
  https://docs.openstack.org/hacking/latest/
- Step 2: Read on

Senlin Specific Commandments
----------------------------

- [S318] Use assertion ``assertIsNone(A)`` instead of ``assertEqual(A, None)``
         or ``assertEqual(None, A)``.
- [S319] Use ``jsonutils`` functions rather than using the ``json`` package
         directly.
- [S320] Default arguments of a method should not be mutable.
- [S321] The api_version decorator has to be the first decorator on a method.
- [S322] LOG.warn is deprecated. Enforce use of LOG.warning.
- [S323] Use assertTrue(...) rather than assertEqual(True, ...).

Working on APIs
---------------

If you are proposing new APIs or fixes to existing APIs, please spend some
time reading the guidelines published by the API WorkGroup:

https://git.openstack.org/cgit/openstack/api-wg/tree/guidelines

Any work on improving Senlin's APIs to conform to the guidelines are welcomed.

Creating Unit Tests
-------------------

For every new feature, unit tests should be created that both test and
(implicitly) document the usage of said feature. When submitting a patch to a
bug without a unit test, a new unit test should be added. If a submitted bug
fix does have a unit test, be sure to add a new one that fails without the
patch and passes with the patch.

For more information on creating and running unit tests , please read
senlin/doc/source/contributor/testing.rst. Test guide online link:
https://docs.openstack.org/senlin/latest/contributor/testing.html


Running Tests
-------------

The testing system is based on a combination of `tox` and `testr`. The
canonical approach to running tests is to simply run the command `tox`.
This will create virtual environments, populate them with dependencies and
run all of the tests that OpenStack CI systems run.

Behind the scenes, `tox` is running `ostestr --slowest`, but is set up such
that you can supply any additional arguments to the `ostestr` command.
For example, the following command makes `tox` to tell `ostestr` to add
`--analyze-isolation` to its argument list::

  tox -- --analyze-isolation