Nikola Dipanov d13012da9d Make Nova better at keeping track of volume sizes in BDM
Up until now we would really only care about the size of ephemeral and
swap BDM entries'volume_size' being set properly, while we would rely on
Cinder to be the canonical source of truth for the size information of
snapshots and volumes.

There is some overhead in querying Cinder every time this basic
information is needed, and we do have a volume_size field in all BDM
entries already, so let's keep it up to date.

Change-Id: I9ffbb6cf40c1012f774a382cf1dcceba64637e6d
Related-bug: #1370177
2015-07-02 13:45:36 +01:00
..
2015-06-18 16:55:26 -04:00
2015-02-22 07:56:40 -05:00
2015-05-20 14:31:33 +03:00
2015-05-07 13:18:19 -07:00
2015-05-20 15:19:51 -07:00
2015-05-20 15:19:51 -07:00

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

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↩︎