Rick Harris
4e560d49d4
Tests that define both Mox and Stubs may not receive a proper cleanup by the
`TestCase` base class. The reason is that the order in which the Mox and Stubs
are unset may not necessarily match-up with the order in which the tests
called them. For example:
Suppose we have a test that Stubs a method in its `setUp` and then Mox's that
same method in the test body:
Stub: Original-Func -> Stubbed-Func
Mox: Stubbed-Func -> Mocked-Func
Now when `TestCase` ultimately does its `cleanUp`, it will UnStub before
UnMocking:
UnStub: Stubbed-Func -> Original-Func
UnMox: Mocked-Func -> Stubbed-Func
Notice that generic cleanup has mistakingly left `Stubbed-Func` in place.
Given that Stubs and Mox can be performed in any order, the upshot here is
that the generic cleanup can't always be relied on.
The proposed solution has two parts: a best-practice change and a small
code-change.
The code-change is to reverse the current order to UnMox before UnStubbing.
While in theory the order is arbitrary, in practice, we have lots of Stubs in
`setUp` methods already, so UnMox'ing first makes sense (and it fixes a
current bug to boot!)
The best-practice change is to recommend against stubbing and mocking the same
function as well as to always place stubs before mocks when relying on the
generic cleanup. If a developers needs to deviate from this, cleanup of stubs
created after mocks are their responsibility.
Fixes bug 1180671
Change-Id: I42ab8b55026c0a133625a7cc81ed8b960e9d47d7
OpenStack Nova README ===================== OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of virtualization technologies, including KVM, Xen, LXC, VMware, and more. In addition to its native API, it includes compatibility with the commonly encountered Amazon EC2 and S3 APIs. OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file. Nova primarily consists of a set of Python daemons, though it requires and integrates with a number of native system components for databases, messaging and virtualization capabilities. To keep updated with new developments in the OpenStack project follow `@openstack <http://twitter.com/openstack>`_ on Twitter. To learn how to deploy OpenStack Nova, consult the documentation available online at: http://docs.openstack.org For information about the different compute (hypervisor) drivers supported by Nova, read this page on the wiki: https://wiki.openstack.org/wiki/HypervisorSupportMatrix In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at: http://bugs.launchpad.net/nova Developers wishing to work on the OpenStack Nova project should always base their work on the latest Nova code, available from the master GIT repository at: http://github.com/openstack/nova Developers should also join the discussion on the mailing list, at: https://lists.launchpad.net/openstack/ Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests. Further developer focused documentation is available at: http://nova.openstack.org/ For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst file. -- End of broadcast