Merge "Update and move test README.rst"
This commit is contained in:
Zuul
Gerrit Code Review
commit
096c9d0d81
|
|
@ -0,0 +1,55 @@
|
|||
==========================================
|
||||
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.
|
||||
|
||||
.. _gabbi: https://gabbi.readthedocs.io/
|
||||
.. _contributor docs: https://docs.openstack.org/placement/latest/contributor/
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
=====================================
|
||||
OpenStack Nova Testing Infrastructure
|
||||
=====================================
|
||||
|
||||
This README file attempts to provide current and prospective contributors with
|
||||
everything they need to know in order to start creating unit tests for nova.
|
||||
|
||||
Note: the content for the rest of this file will be added as the work items in
|
||||
the following blueprint are completed:
|
||||
https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure
|
||||
|
||||
|
||||
Test Types: Unit vs. Functional vs. Integration
|
||||
-----------------------------------------------
|
||||
|
||||
TBD
|
||||
|
||||
Writing Unit Tests
|
||||
------------------
|
||||
|
||||
TBD
|
||||
|
||||
Using Fakes
|
||||
~~~~~~~~~~~
|
||||
|
||||
TBD
|
||||
|
||||
test.TestCase
|
||||
-------------
|
||||
The TestCase class from nova.test (generally imported as test) will
|
||||
automatically manage self.stubs using the stubout module and self.mox
|
||||
using the mox module during the setUp step. They will automatically
|
||||
verify and clean up during the tearDown step.
|
||||
|
||||
If using test.TestCase, calling the super class setUp is required and
|
||||
calling the super class tearDown is required to be last if tearDown
|
||||
is overridden.
|
||||
|
||||
Writing Functional Tests
|
||||
------------------------
|
||||
|
||||
TBD
|
||||
|
||||
Writing Integration Tests
|
||||
-------------------------
|
||||
|
||||
TBD
|
||||
|
||||
Tests and Exceptions
|
||||
--------------------
|
||||
A properly written test asserts that particular behavior occurs. This can
|
||||
be a success condition or a failure condition, including an exception.
|
||||
When asserting that a particular exception is raised, the most specific
|
||||
exception possible should be used.
|
||||
|
||||
In particular, testing for Exception being raised is almost always a
|
||||
mistake since it will match (almost) every exception, even those
|
||||
unrelated to the exception intended to be tested.
|
||||
|
||||
This applies to catching exceptions manually with a try/except block,
|
||||
or using assertRaises().
|
||||
|
||||
Example::
|
||||
|
||||
self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid,
|
||||
elevated, instance_uuid)
|
||||
|
||||
If a stubbed function/method needs a generic exception for testing
|
||||
purposes, test.TestingException is available.
|
||||
|
||||
Example::
|
||||
|
||||
def stubbed_method(self):
|
||||
raise test.TestingException()
|
||||
self.stubs.Set(cls, 'inner_method', stubbed_method)
|
||||
|
||||
obj = cls()
|
||||
self.assertRaises(test.TestingException, obj.outer_method)
|
||||
|
||||
|
||||
Stubbing and Mocking
|
||||
--------------------
|
||||
|
||||
Whenever possible, tests SHOULD NOT stub and mock out the same function.
|
||||
|
||||
If it's unavoidable, tests SHOULD define stubs before mocks since the
|
||||
`TestCase` cleanup routine will un-mock before un-stubbing. Doing otherwise
|
||||
results in a test that leaks stubbed functions, causing hard-to-debug
|
||||
interference between tests [1]_.
|
||||
|
||||
If a mock must take place before a stub, any stubs after the mock call MUST be
|
||||
manually unset using `self.cleanUp` calls within the test.
|
||||
|
||||
|
||||
.. [1] https://bugs.launchpad.net/nova/+bug/1180671
|
||||
Loading…
Reference in New Issue