| Matthew Treinish | a9aef87 | 2014-07-25 16:03:08 -0400 | [diff] [blame] | 1 | .. _api_field_guide: |
| 2 | |
| Masayuki Igawa | c268dd6 | 2013-09-18 00:51:05 +0900 | [diff] [blame] | 3 | Tempest Field Guide to API tests |
| 4 | ================================ |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 5 | |
| 6 | |
| 7 | What are these tests? |
| Attila Fazekas | 23fdf1d | 2013-06-09 16:35:23 +0200 | [diff] [blame] | 8 | --------------------- |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 9 | |
| 10 | One of Tempest's prime function is to ensure that your OpenStack cloud |
| 11 | works with the OpenStack API as documented. The current largest |
| 12 | portion of Tempest code is devoted to test cases that do exactly this. |
| 13 | |
| Yong Sheng Gong | e99072d | 2013-08-15 13:52:41 +0800 | [diff] [blame] | 14 | It's also important to test not only the expected positive path on |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 15 | APIs, but also to provide them with invalid data to ensure they fail |
| 16 | in expected and documented ways. Over the course of the OpenStack |
| 17 | project Tempest has discovered many fundamental bugs by doing just |
| 18 | this. |
| 19 | |
| Yong Sheng Gong | e99072d | 2013-08-15 13:52:41 +0800 | [diff] [blame] | 20 | In order for some APIs to return meaningful results, there must be |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 21 | enough data in the system. This means these tests might start by |
| Yong Sheng Gong | e99072d | 2013-08-15 13:52:41 +0800 | [diff] [blame] | 22 | spinning up a server, image, etc, then operating on it. |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 23 | |
| 24 | |
| 25 | Why are these tests in tempest? |
| Attila Fazekas | 23fdf1d | 2013-06-09 16:35:23 +0200 | [diff] [blame] | 26 | ------------------------------- |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 27 | |
| 28 | This is one of the core missions for the Tempest project, and where it |
| 29 | started. Many people use this bit of function in Tempest to ensure |
| 30 | their clouds haven't broken the OpenStack API. |
| 31 | |
| 32 | It could be argued that some of the negative testing could be done |
| 33 | back in the projects themselves, and we might evolve there over time, |
| 34 | but currently in the OpenStack gate this is a fundamentally important |
| 35 | place to keep things. |
| 36 | |
| 37 | |
| 38 | Scope of these tests |
| Attila Fazekas | 23fdf1d | 2013-06-09 16:35:23 +0200 | [diff] [blame] | 39 | -------------------- |
| Sean Dague | 1937d09 | 2013-05-17 16:36:38 -0400 | [diff] [blame] | 40 | |
| 41 | API tests should always use the Tempest implementation of the |
| 42 | OpenStack API, as we want to ensure that bugs aren't hidden by the |
| 43 | official clients. |
| 44 | |
| 45 | They should test specific API calls, and can build up complex state if |
| 46 | it's needed for the API call to be meaningful. |
| 47 | |
| 48 | They should send not only good data, but bad data at the API and look |
| 49 | for error codes. |
| 50 | |
| 51 | They should all be able to be run on their own, not depending on the |
| 52 | state created by a previous test. |