openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/scenario
History
Lucas Alvares Gomes 0976ae4ee2 Skip test_qos_min_bw_allocation_basic when not supported 
The test_qos_min_bw_allocation_basic relies on a feature [0] which is
not supported by all Neutron backends. This test for example will fail
for OVN until [0] is implemented for it.

This patch makes the test skippable instead of failing when the backend
does not support it.

[0]
https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html

Change-Id: I608c123e69b2e1b34fa0783d03ee5603d901351d
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
 		2020-09-01 10:09:29 +01:00
..
README.rst Fix docs markup consistency 2017-11-21 19:02:54 +09:00
__init__.py add scenario directory 2013-05-17 08:52:22 -04:00
manager.py Use of single interface for creating image 2020-08-28 12:14:25 +05:30
test_aggregates_basic_ops.py Replace list_hypervisors with list_services 2018-04-04 10:28:40 +03:00
test_encrypted_cinder_volumes.py Use of single interface for creating image 2020-08-28 12:14:25 +05:30
test_minbw_allocation_placement.py Skip test_qos_min_bw_allocation_basic when not supported 2020-09-01 10:09:29 +01:00
test_minimum_basic.py Use of single interface for creating image 2020-08-28 12:14:25 +05:30
test_network_advanced_server_ops.py Unstable test_server_connectivity_cold_migration_revert 2020-06-23 16:46:15 +00:00
test_network_basic_ops.py Merge "Remove any reference to "tenant_id" in network" 2020-07-10 00:40:03 +00:00
test_network_v6.py Improve ipv6 configuration 2019-05-03 18:55:40 +00:00
test_object_storage_basic_ops.py docs: Fix incorrect docstrings in reStructuredText format 2018-11-21 19:06:43 -06:00
test_security_groups_basic_ops.py Remove any reference to "tenant_id" in network 2020-06-02 08:28:47 +00:00
test_server_advanced_ops.py Trivial docstring cleanup in TestServerAdvancedOps 2018-04-25 16:17:03 -04:00
test_server_basic_ops.py Update json module to jsonutils 2019-03-06 22:54:51 +08:00
test_server_multinode.py Move test decorators to common 2017-08-23 17:09:33 +00:00
test_shelve_instance.py Log server console output during create/get timestamp 2018-07-30 22:46:56 +02:00
test_snapshot_pattern.py Add image "version" metadata in test_snapshot_pattern 2020-05-22 16:53:48 +00:00
test_stamp_pattern.py Fix test_stamp_pattern to remove dependency of user supplied volume name 2020-01-24 19:19:45 -05:00
test_volume_backup_restore.py Add status check for creating volume backup 2018-06-19 01:08:28 +00:00
test_volume_boot_pattern.py Use new encryption provider constants (reprise) 2020-04-22 12:34:46 +02:00
test_volume_migrate_attached.py Introduce an attached volume migration test 2019-04-25 10:34:58 +01:00

README.rst

Tempest Field Guide to Scenario tests

What are these tests?

Scenario tests are "through path" tests of OpenStack function. Complicated setups where one part might depend on completion of a previous part. They ideally involve the integration between multiple OpenStack services to exercise the touch points between them.

Any scenario test should have a real-life use case. An example would be:

  • "As operator I want to start with a blank environment":
    1. upload a glance image
    2. deploy a vm from it
    3. ssh to the guest
    4. create a snapshot of the vm

Why are these tests in Tempest?

This is one of Tempest's core purposes, testing the integration between projects.

Scope of these tests

Scenario 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.

Tests should be tagged with which services they exercise, as determined by which client libraries are used directly by the test.

Example of a good test

While we are looking for interaction of 2 or more services, be specific in your interactions. A giant "this is my data center" smoke test is hard to debug when it goes wrong.

A flow of interactions between Glance and Nova, like in the introduction, is a good example. Especially if it involves a repeated interaction when a resource is setup, modified, detached, and then reused later again.