blob: 64bd2c28f1b67482c0c39be29ff1b7097129209e [file] [log] [blame]
Matthew Treinish55511d92016-02-23 10:55:53 -05001.. _library:
2
Rodrigo Duarte6af041a2016-03-07 12:17:08 -03003Tempest Library Documentation
Matthew Treinish55511d92016-02-23 10:55:53 -05004=============================
5
6Tempest provides a stable library interface that provides external tools or
7test suites an interface for reusing pieces of tempest code. Any public
8interface that lives in tempest/lib in the tempest repo is treated as a stable
9public interface and it should be safe to external consume that. Every effort
10goes into maintaining backwards compatibility with any change. Just as with
11tempest-lib the library is self contained and doesn't have any dependency on
12other tempest internals outside of lib. (including no usage of tempest
13configuration)
14
15Stability
16---------
17Just as tempest-lib before it any code that lives in tempest/lib will be treated
18as a stable interface, nothing has changed in regards to interface stability.
19This means that any public interface under the tempest/lib directory is
20expected to be a stable interface suitable for public consumption. However, for
21any interfaces outside of tempest/lib in the tempest tree (unless otherwise
22noted) or any private interfaces the same stability guarantees don't apply.
23
24Adding Interfaces
25'''''''''''''''''
26When adding an interface to tempest/lib we have to make sure there are no
27dependencies on any pieces of tempest outside of tempest/lib. This means if
28for example there is a dependency on the configuration file we need remove that.
29The other aspect when adding an interface is to make sure it's really an
30interface ready for external consumption and something we want to commit to
31supporting.
32
33Making changes
34''''''''''''''
35When making changes to tempest/lib you have to be conscious of the effect of
36any changes on external consumers. If your proposed changeset will change the
37default behaviour of any interface, or make something which previously worked
38not after your change, then it is not acceptable. Every effort needs to go into
39preserving backwards compatibility in changes.
40
41Reviewing
42'''''''''
43When reviewing a proposed change to tempest/lib code we need to be careful to
44ensure that we don't break backwards compatibility. For patches that change
45existing interfaces we have to be careful to make sure we don't break any
46external consumers. Some common red flags are:
47
48 * a change to an existing API requires a change outside the library directory
49 where the interface is being consumed
50 * a unit test has to be significantly changed to make the proposed change pass
51
52Testing
53'''''''
54When adding a new interface to the library we need to at a minimum have unit
55test coverage. A proposed change to add an interface to tempest/lib that
56doesn't have unit tests shouldn't be accepted. Ideally these unit tests will
57provide sufficient coverage to ensure a stable interface moving forward.
58
59Current Library APIs
60--------------------
61
62.. toctree::
63 :maxdepth: 2
64
65 library/cli
66 library/decorators
67 library/rest_client
68 library/utils
Ghanshyam1f47cf92016-02-25 04:57:18 +090069 library/api_microversion_testing