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