openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/api
History
Lukáš Piwowarski 553d91b51e Fix cleanup for object_storage tests 
This reverts change I98a75cbf119ba8126253a681c046f4cf44b1607e.

Volume backup tests create a container when Swift is used as a backup
driver. This causes a failure of an object storage test [1] as it
expects no containers being present before the testing.

This patch fixes the cleanup by deleting properly the containers
created during the volume backup tests. Before the deletion we check
using a new tempest.conf option whether swift is used as a backup
driver.

This patche also un-skips the
test_volume_backup_create_get_detailed_list_restore_delete test as the
patch ensures that we do not use the container parameter in the API
call when Swift is not used as a backup driver.

[1] https://opendev.org/openstack/tempest/src/tempest/api/object_storage/test_account_services.py#L67

Closes-Bug: #2034913
Change-Id: I33ba1838bf0bfcf94424e7288249dae3feeeb2a2
 		2023-10-09 07:28:50 +00:00
..
compute Fix the unstable_test syntax for test_live_migration_with_trunk 2023-09-15 10:23:01 -07:00
identity Fix clean up for test_access_rules tests 2023-08-29 21:47:34 +02:00
image Remove Glance v1 APIs tests 2023-08-14 11:35:59 +02:00
network Remove test duplication between tempest and n-t-p QuotasTest 2023-09-14 10:51:28 +02:00
object_storage Fix cleanup for object_storage tests 2023-10-09 07:28:50 +00:00
volume Fix cleanup for object_storage tests 2023-10-09 07:28:50 +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.