History

Dan Smith 60364b39f1 Revert "Adds tests for resize server for swap"

The test_flavor_swap_1024_to_0() test seems to be failing to assert
zero swap devs after the resize very frequently. This has been merged
for less than 24 hours so I'm proposing this revert to avoid blocking
the gate.

This reverts commit a20f89d20c04a5b8e8887a659c76be2e780b3484.

Change-Id: I4184abbc85368affe557005628f6385c224ffe73

2025-04-04 12:15:17 -07:00

compute

Revert "Adds tests for resize server for swap"

2025-04-04 12:15:17 -07:00

identity

Bump hacking

2024-11-14 23:39:15 +09:00

image

Allow glance support for GPT images

2024-11-13 07:25:18 -08:00

network

Wait for the router port activation before deletion

2024-12-05 09:44:38 +00:00

object_storage

[codespell] fix typos

2024-04-02 12:12:32 +05:30

volume

Use create_volume wrapper instead of volumes_client

2025-03-28 13:51:53 -07:00

__init__.py

Remove copyright from empty files

2014-01-14 03:02:04 +04:00

README.rst

General doc updates

2024-01-31 09:00:16 +01:00

README.rst

Tempest Field Guide to API tests

What are these tests?

One of Tempest's prime functions 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. Throughout 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., and 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 states 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.