ba0339f413
There was an exceptionally large amount of rote use of _get_regexes throughout the samples tests, which doesn't provide any additional explicitness in what's happening, and only couples the tests to the base class in less useful ways. Instead, when we call _verify_response, always also use the base vanilla regexes for matching tests. We also needed to add a few more variables to the list which always need to be reset before testing against the static samples, because uuids are often generated on the fly for the tests. Lastly, test_keypairs needed some test specific surgery. It is so highly normalized (with private test methods that take **kwargs) at this point that it's not really clear that it's testing useful things any more. This really needs denormalization. Change-Id: I165b0f3aa2132373cb59982a5a5ded37b4fa1b52 |
||
|---|---|---|
| .. | ||
| api_samples/os-aggregates | ||
| README.rst | ||
| test_aggregates.py | ||
Api Samples
This part of the tree contains templates for API samples. The documentation in doc/api_samples is completely autogenerated from the tests in this directory.
To add a new api sample, add tests for the common passing and failing cases in this directory for your extension, and modify test_samples.py for your tests.
Then run the following command:
tox -e api-samples
Which will create the files on doc/api_samples.
If new tests are added or the .tpl files are changed due to bug fixes, the samples must be regenerated so they are in sync with the templates, as there is an additional test which reloads the documentation and ensures that it's in sync.
Debugging sample generation
If a .tpl is changed, its matching .json must be removed else the samples won't be generated. If an entirely new extension is added, a directory for it must be created before its samples will be generated.