Files
tempest/tempest/scenario
Jordan Pittier 8160d31e58 test.py: stop using aliases for creds manager
It could be confusing to new comers that the variables
cls.os and cls.os_primary or cls.alt_manager and cls.os_alt
actually are aliases. Besides we are not consistent in their usage.

This patch normalizes the usage around os_admin, os_primary and
os_alt. We keep the old aliases for compatibility but we should not
use them anymore.

This fix a long standing TODO item.

Change-Id: I5f7164f7a7ec5d4380ca22885000caa0183a0bf7
2017-04-26 10:34:56 +02:00
..
2013-05-17 08:52:22 -04:00
2017-03-01 10:09:55 +00:00

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.