History

Balazs Gibizer 55414580c2 Remove race from wait_for_interface_detach waiter Nova list the interfaces attached to a server based on list of ports bound to the server. However during detach interface nova unbounds the port first and then deallocates the resources used by that port in placement. The current detach waiter only waits until the interface disappears from the interface list. This can cause that waiter returns before the resource allocation is removed from placement cause a race in the test asserting such allocation. So this patch changes the waiter to wait for the successful detach os-instance-action event for the server as that is only recorded after the port is fully deallocated. blueprint: qos-minimum-guaranteed-packet-rate Change-Id: I8740f8e0cc18ffea31a9a068bccee50bf4e6fe28		2021-11-04 13:32:55 +01:00
..
compute	Remove race from wait_for_interface_detach waiter	2021-11-04 13:32:55 +01:00
identity	Fixes test_user_update_own_password test cleanup problem (New password cannnot be identical to a previous password)	2021-08-09 08:44:02 +02:00
image	Add wait to check the import task status	2021-04-30 13:01:02 -05:00
network	Fix unused parameters in _create_subnet method	2021-09-09 11:13:09 +08:00
object_storage	Improve cleanup after Swift testing	2021-10-05 14:31:04 +00:00
volume	Use lib.commom.api_microversion_fixture to set volume, compute API microversion in volume API testing	2021-10-15 17:13:25 +00:00
README.rst	Doc: fix markups, capitalization and add 2 REVIEWING advices	2017-07-11 20:26:32 +02:00
__init__.py	Remove copyright from empty files	2014-01-14 03:02:04 +04:00

README.rst

Tempest Field Guide to API tests

What are these tests?

One of Tempest's prime function is to ensure that your OpenStack cloud works with the OpenStack API as documented. The current largest portion of Tempest code is devoted to test cases that do exactly this.

It's also important to test not only the expected positive path on APIs, but also to provide them with invalid data to ensure they fail in expected and documented ways. The latter type of tests is called negative tests in Tempest source code. Over the course of the OpenStack project Tempest has discovered many fundamental bugs by doing just this.

In order for some APIs to return meaningful results, there must be enough data in the system. This means these tests might start by spinning up a server, image, etc, then operating on it.

Why are these tests in Tempest?

This is one of the core missions for the Tempest project, and where it started. Many people use this bit of function in Tempest to ensure their clouds haven't broken the OpenStack API.

It could be argued that some of the negative testing could be done back in the projects themselves, and we might evolve there over time, but currently in the OpenStack gate this is a fundamentally important place to keep things.

Scope of these tests

API tests should always use the Tempest implementation of the OpenStack API, as we want to ensure that bugs aren't hidden by the official clients.

They should test specific API calls, and can build up complex state if it's needed for the API call to be meaningful.

They should send not only good data, but bad data at the API and look for error codes.

They should all be able to be run on their own, not depending on the state created by a previous test.