History

Chris Dent 0c9b38a88e Add register_opts param to PlacementFixture There are scenarios where it is useful to create a ConfigOpts and register_opts on it before ever calling the PlacementFixture. If that is done we don't want to re-register the opts within the fixture as this can lead to errors (especially when CLI opts are involved). The scenario that discovered this problem is in nova in a regression test [1] where a ConfigOpts is created and registered, the placement DatabaseFixture is started and then that same config is used in multiple instances of the PlacementFixture, each of which again register_opts(). Until commit `b647919666` this wasn't a problem because the default opts in placement did not include any CLI options. Adding logging opts brought some in. This change adds a flag to the constructor for PlacementFixture, register_opts, defaulting to True, which lets the caller say no, I don't want do register. The version of this change on master also reverted the revert of `b647919666` to perform oslo_log.log.register_opts() from a central location. That doesn't happen here because that revert (which was an interim quick fix) was not backported to stable/stein. [1] test_bug_1679750.TestLocalDeleteAllocations.test_local_delete_removes_allocations_after_compute_restart Change-Id: I360a306b5d05ada75274733038b73ec2f2bdc4d4 Needed-By: I042e41ac8c41c0e5f0389904eb548e0e97d54c60 Related-Bug: #1821092 (cherry picked from commit `f7f5231677`)		2019-03-21 13:27:40 +00:00
..
functional	Add register_opts param to PlacementFixture	2019-03-21 13:27:40 +00:00
unit	Remove InventoryList class	2019-03-13 21:24:34 +00:00
README.rst	Link to tempest doc in tests/README.rst	2018-09-14 09:32:27 -06:00
__init__.py	Rename the 'nova' directories to 'placement'	2018-09-04 10:31:22 -05:00
fixtures.py	Move Trait and TraitList to own module	2019-03-13 21:24:34 +00:00

README.rst

OpenStack Placement Testing Infrastructure

This README file attempts to provides some brief guidance for writing tests when fixing bugs or adding features to placement.

For a lot more information see the contributor docs.

Test Types: Unit vs. Functional vs. Integration

Placement tests are divided into three types:

Unit: tests which confirm the behavior of individual pieces of the code (individual methods or classes) with minimal dependency on other code or on externals like the database.
Functional: tests which confirm a chunk of behavior, end to end, such as an HTTP endpoint accepting a body from a request and returning the expected response but without reliance on code or services that are external to placement.
Integration: tests that confirm that things work with other services, such as nova.

Placement uses all three, but the majority are functional tests. This is the result of the fairly direct architecture of placement: It is a WSGI application that talks to a database.

Writing Unit Tests

Placement unit tests are based on the TestCase that comes with the testtools package. Use mocks only as necessary. If you find that you need multiple mocks to make a test for the code you are testing may benefit from being refactored to smaller units.

Writing Functional Tests

There are two primary classes of functional test in placement:

Testing database operations. These are based on placement.tests.functional.base.TestCase which is responsible for starting an in-memory database and a reasonable minimal configuration.
Testing the HTTP API using gabbi.

Writing Integration Tests

Placement configures its gate and check jobs via the .zuul.yaml file in the root of the code repository. Some of the entries in that file configure integration jobs, many of which use tempest.