openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/scenario
History
Andrea Frittoli b21de6ce45 Initial class creds creation in test base class 
Each test class may now define at class level which credentials
are needed, and they will be allocated automatically by the base
class. To start using this a test class that requires network
resources must implement the setup_credentials method and
define the required resources before super is invoked.

In this patch this only affects the creation of credentials
as defined in the various base classes. Other tests will be
migrated as part of the resource-cleanup bp. Note that this
changes baremetal, identity and orchestration tests to
honour the tenant isolation settings.

Partially-implements: bp resource-cleanup

Change-Id: Id36a6ebddb618a78cee7025c9537cd1e2746190e
 		2015-04-27 15:23:13 +01:00
..
README.rst Fix doc for usage of python clients in scenario tests 2014-11-26 17:04:37 +09:00
__init__.py add scenario directory 2013-05-17 08:52:22 -04:00
manager.py Initial class creds creation in test base class 2015-04-27 15:23:13 +01:00
test_aggregates_basic_ops.py Initial class creds creation in test base class 2015-04-27 15:23:13 +01:00
test_baremetal_basic_ops.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_dashboard_basic_ops.py Initial class creds creation in test base class 2015-04-27 15:23:13 +01:00
test_encrypted_cinder_volumes.py Distinguish between luks and cryptsetup volume types 2015-03-13 09:50:52 -07:00
test_large_ops.py Remove hyphen from rand_name calls in scenario tests 2015-03-30 01:24:05 +00:00
test_load_balancer_basic.py Direct ssh bash output to /dev/null 2015-04-22 10:30:07 +03:00
test_minimum_basic.py Apply a naming rule of GET to volume client 2015-04-07 05:24:00 +00:00
test_network_advanced_server_ops.py Merge "Allow sress test runner to skip based on available services" 2015-03-20 22:48:40 +00:00
test_network_basic_ops.py Merge "Adding port_admin_state_change option to config" 2015-04-20 22:24:10 +00:00
test_network_v6.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_security_groups_basic_ops.py Initial class creds creation in test base class 2015-04-27 15:23:13 +01:00
test_server_advanced_ops.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_server_basic_ops.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_shelve_instance.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_snapshot_pattern.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_stamp_pattern.py Apply a naming rule of GET to volume client 2015-04-07 05:24:00 +00:00
test_swift_basic_ops.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_swift_telemetry_middleware.py Update all Oslo module use 2015-03-11 21:07:56 +00:00
test_volume_boot_pattern.py Skip test_volume_boot_pattern until bug 1439371 is fixed 2015-04-06 08:51:16 -07:00
utils.py Remove migrated utils code 2015-03-06 19:16:10 -05: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 tempests 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.