Files

T

melanie witt 334f313220 Add CONF.compute_feature_enabled.volume_backed_live_migration

The test_volume_backed_live_migration test has been skipped for some
time because of a bug [1] which could possibly be resolved with newer
libvirt and qemu package versions available in the pike UCA.

This changes the unconditional skip to a config option controlled skip
so that we can try re-enabling this test on the master branch for nova
changes.

[1] https://bugs.launchpad.net/nova/+bug/1524898

Change-Id: I78ceb1aaa3e96f6b76fa94aba50527022c3e2d45

2017-12-15 16:53:56 +00:00

compute

Add CONF.compute_feature_enabled.volume_backed_live_migration

2017-12-15 16:53:56 +00:00

identity

Merge "Stop using resource_cleanup in identity_v3 tests"

2017-12-11 17:43:03 +00:00

image

Use addClassResourceCleanup in BaseImageTest

2017-11-06 15:22:29 +08:00

network

Use addClassResourceCleanup to cleanup floatingips

2017-11-22 13:34:40 +08:00

object_storage

Fix object_client methods to accept headers and query param

2017-10-11 08:05:22 +00:00

volume

Merge "Add update groups types API endpoint to volumes v3 library"

2017-12-14 03:24:07 +00:00

__init__.py

Remove copyright from empty files

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

README.rst

Doc: fix markups, capitalization and add 2 REVIEWING advices

2017-07-11 20:26:32 +02: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.