openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/scenario
History
David Kranz 34f18782fa Change image client methods to return one value 
Tests were updated along with verify_tempest, cleanup, javelin.
There were two methods in the clients where the body is a string. Since
strings are immutable a more complicated way would have to be created to
return a single value that could be used transparently by clients. So
these methods continue to return (response, body).

Partially implements: blueprint clients-return-one-value

Change-Id: Id6a728d1ea1cf233ae580fdcd305dc42a4f3610f
 		2015-01-06 17:22:24 -05:00
..
orchestration Scenario manager: catch Exception in get_remote_client 2014-11-26 10:46:54 +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 Change image client methods to return one value 2015-01-06 17:22:24 -05:00
test_aggregates_basic_ops.py Migrate scenario tests to resource_* fixtures 2014-10-03 12:18:53 +01:00
test_baremetal_basic_ops.py Change neutron client methods to return one value and update tests 2014-12-18 09:56:18 -05:00
test_dashboard_basic_ops.py Use isolated creds for dashboard scenario 2014-12-12 23:15:26 -05:00
test_encrypted_cinder_volumes.py Migrate test_encrypted_cinder_volumes to tempest client 2014-09-10 13:58:55 +09:00
test_large_ops.py Merge "Remove unnecessary secgroup attrs from scenario tests" 2014-12-03 13:05:58 +00:00
test_load_balancer_basic.py Remove use of 'cls.enabled = False' 2014-12-12 11:07:39 -08:00
test_minimum_basic.py Scenario manager: catch Exception in get_remote_client 2014-11-26 10:46:54 +01:00
test_network_advanced_server_ops.py Remove use of 'cls.enabled = False' 2014-12-12 11:07:39 -08:00
test_network_basic_ops.py Remove use of 'cls.enabled = False' 2014-12-12 11:07:39 -08:00
test_network_v6.py Merge "Fix ipv6 network scenario in multi-network environment" 2014-12-18 07:26:43 +00:00
test_security_groups_basic_ops.py Remove use of 'cls.enabled = False' 2014-12-12 11:07:39 -08:00
test_server_advanced_ops.py Fix resource_setup order in scenarios 2014-10-15 17:38:30 +09:00
test_server_basic_ops.py Merge "Scenario manager: catch Exception in get_remote_client" 2014-12-09 11:16:25 +00:00
test_shelve_instance.py Remove unnecessary secgroup attrs from scenario tests 2014-12-02 10:48:20 +00:00
test_snapshot_pattern.py Merge "Scenario manager: catch Exception in get_remote_client" 2014-12-09 11:16:25 +00:00
test_stamp_pattern.py Remove unnecessary secgroup attrs from scenario tests 2014-12-02 10:48:20 +00:00
test_swift_basic_ops.py Add ca_certificates_file option to test against SSL servers 2014-12-03 02:11:48 -05:00
test_swift_telemetry_middleware.py Add check for too_slow_to_test flag on swift notification test 2014-11-20 17:26:28 -05:00
test_volume_boot_pattern.py Scenario manager: catch Exception in get_remote_client 2014-11-26 10:46:54 +01:00
utils.py Fix unit tests to detect import failures 2014-10-27 10:01:16 -04: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.