openstack
/
tempest
Code Issues Proposed changes
tempest/tempest/scenario
History
Sean Dague 1937d09fb0 rename tests -> api 
Now that all the other tests are moved out of the tests directory
we can rename tests -> api to reflect that these tests are api
testing, and need to use only the internal clients.

Clean up references from other parts of OpenStack to the new api
namespace.

Reorder the imports as required with this naming change.

Added README.rst

Change-Id: I19203957f917b59e7c8a3838c590937752461a2f
 		2013-05-20 17:20:54 -04:00
..
README.rst add scenario directory 2013-05-17 08:52:22 -04:00
__init__.py add scenario directory 2013-05-17 08:52:22 -04:00
manager.py rename tests -> api 2013-05-20 17:20:54 -04:00
test_network_basic_ops.py rename tests -> api 2013-05-20 17:20:54 -04:00
test_network_quotas.py add scenario directory 2013-05-17 08:52:22 -04:00
test_server_advanced_ops.py add scenario directory 2013-05-17 08:52:22 -04:00
test_server_basic_ops.py add scenario directory 2013-05-17 08:52:22 -04:00

README.rst

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

An example would be: start with a blank environment, upload a glance image, deploy a vm from it, ssh to the guest, make changes, capture that vm's image back into glance as a snapshot, and launch a second vm from that snapshot.

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 test at least 2 services in interaction. They should use the official python client libraries for OpenStack, as they provide a more realistic approach in how people will interact with the services.

TODO: once we have service tags, tests should be tagged with which services they exercise.

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.