Notes on Trove Unit Tests

Notes on Trove Unit Tests

Mock Object Library

Trove unit tests make a frequent use of the Python Mock library. This library lets the caller replace (“mock”) parts of the system under test with mock objects and make assertions about how they have been used. 1

The Problem of Dangling Mocks

Often one needs to mock global functions in shared system modules. The caller must restore the original state of the module after it is no longer required.

Dangling mock objects in global modules (mocked members of imported modules that never get restored) have been causing various transient failures in the unit test suite.

The main issues posed by dangling mock objects include:

- Such object references propagate across the entire test suite. Any
caller may be hit by a non-functional - or worse - crippled module member
because some other (potentially totally unrelated) test case failed to
restore it.

- Dangling mock references shared across different test modules may
lead to unexpected results/behavior in multi-threaded environments. One
example could be a test case failing because a mock got called multiple
times from unrelated modules.

Such issues are likely to exhibit transient random behavior depending on the runtime environment, making them difficult to debug.

There are several possible strategies available for dealing with dangling mock objects (see the section on recommended patterns). Further information is available in 1, 2, 3.

Dangling Mock Detector

All Trove unit tests should extend ‘trove_testtools.TestCase’. It is a subclass of ‘testtools.TestCase’ which automatically checks for dangling mock objects at each test class teardown. It marks the tests as failed and reports the leaked reference if it finds any.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.