← Back to branch summary

~ubuntu-branches/ubuntu/raring/nova/raring-proposed

« back to all changes in this revision

Viewing changes to nova/tests/hyperv/README.rst

  • Committer: Package Import Robot
  • Author(s): Chuck Short, Adam Gandelman, Chuck Short
  • Date: 2012-11-23 09:04:58 UTC
  • mfrom: (1.1.66)
  • Revision ID: package-import@ubuntu.com-20121123090458-91565o7aev1i1h71
Tags: 2013.1~g1-0ubuntu1
https://launchpad.net/bugs/1073289
https://launchpad.net/bugs/1076442
[ Adam Gandelman ]
* debian/control: Ensure novaclient is upgraded with nova,
  require python-keystoneclient >= 1:2.9.0. (LP: #1073289)
* debian/patches/{ubuntu/*, rbd-security.patch}: Dropped, applied
  upstream.
* debian/control: Add python-testtools to Build-Depends.

[ Chuck Short ]
* New upstream version.
* Refreshed debian/patches/avoid_setuptools_git_dependency.patch.
* debian/rules: FTBFS if missing binaries.
* debian/nova-scheudler.install: Add missing rabbit-queues and
  nova-rpc-zmq-receiver.
* Remove nova-volume since it doesnt exist anymore, transition to cinder-*.
* debian/rules: install apport hook in the right place.
* debian/patches/ubuntu-show-tests.patch: Display test failures.
* debian/control: Add depends on genisoimage
* debian/control: Suggest guestmount.
* debian/control: Suggest websockify. (LP: #1076442)
* debian/nova.conf: Disable nova-volume service.
* debian/control: Depend on xen-system-* rather than the hypervisor.
* debian/control, debian/mans/nova-conductor.8, debian/nova-conductor.init,
  debian/nova-conductor.install, debian/nova-conductor.logrotate
  debian/nova-conductor.manpages, debian/nova-conductor.postrm
  debian/nova-conductor.upstart.in: Add nova-conductor service.
* debian/control: Add python-fixtures as a build deps.

Show diffs side-by-side

added added

removed removed

Lines of Context:
nova/tests/hyperv/README.rst
 
1
=====================================
 
2
OpenStack Hyper-V Nova Testing Architecture
 
3
=====================================
 
4
 
 
5
The Hyper-V Nova Compute plugin uses Windows Management Instrumentation (WMI)
 
6
as the main API for hypervisor related operations.
 
7
WMI has a database / procedural oriented nature that can become difficult to
 
8
test with a traditional static mock / stub based unit testing approach.
 
9
 
 
10
The included Hyper-V testing framework has been developed with the
 
11
following goals:
 
12
 
 
13
1) Dynamic mock generation.
 
14
2) Decoupling. No dependencies on WMI or any other module.
 
15
    The tests are designed to work with mocked objects in all cases, including
 
16
    OS-dependent (e.g. wmi, os, subprocess) and non-deterministic
 
17
    (e.g. time, uuid) modules
 
18
3) Transparency. Mocks and real objects can be swapped via DI
 
19
    or monkey patching.
 
20
4) Platform independence.
 
21
5) Tests need to be executed against the real object or against the mocks
 
22
    with a simple configuration switch. Development efforts can highly
 
23
    benefit from this feature.
 
24
6) It must be possible to change a mock's behavior without running the tests
 
25
    against the hypervisor (e.g. by manually adding a value / return value).
 
26
 
 
27
The tests included in this package include dynamically generated mock objects,
 
28
based on the recording of the attribute values and invocations on the
 
29
real WMI objects and other OS dependent features.
 
30
The generated mock objects are serialized in the nova/tests/hyperv/stubs
 
31
directory as gzipped pickled objects.
 
32
 
 
33
An environment variable controls the execution mode of the tests.
 
34
 
 
35
Recording mode:
 
36
 
 
37
NOVA_GENERATE_TEST_MOCKS=True
 
38
Tests are executed on the hypervisor (without mocks), and mock objects are
 
39
generated.
 
40
 
 
41
Replay mode:
 
42
 
 
43
NOVA_GENERATE_TEST_MOCKS=
 
44
Tests are executed with the existing mock objects (default).
 
45
 
 
46
Mock generation is performed by nova.tests.hyperv.mockproxy.MockProxy.
 
47
Instances of this class wrap objects that need to be mocked and act as a
 
48
delegate on the wrapped object by leveraging Python's __getattr__ feature.
 
49
Attribute values and method call return values are recorded at each access.
 
50
Objects returned by attributes and method invocations are wrapped in a
 
51
MockProxy consistently.
 
52
From a caller perspective, the MockProxy is completely transparent,
 
53
with the exception of calls to the type(...) builtin function.
 
54
 
 
55
At the end of the test, a mock is generated by each MockProxy by calling
 
56
the get_mock() method. A mock is represented by an instance of the
 
57
nova.tests.hyperv.mockproxy.Mock class.
 
58
 
 
59
The Mock class task consists of replicating the behaviour of the mocked
 
60
objects / modules by returning the same values in the same order, for example:
 
61
 
 
62
def check_path(path):
 
63
    if not os.path.exists(path):
 
64
        os.makedirs(path)
 
65
 
 
66
check_path(path)
 
67
# The second time os.path.exists returns True
 
68
check_path(path)
 
69
 
 
70
The injection of MockProxy / Mock instances is performed by the
 
71
nova.tests.hyperv.basetestcase.BaseTestCase class in the setUp()
 
72
method via selective monkey patching.
 
73
Mocks are serialized in tearDown() during recording.
 
74
 
 
75
The actual Hyper-V test case inherits from BaseTestCase:
 
76
nova.tests.hyperv.test_hypervapi.HyperVAPITestCase
 
77
 
 
78
 
 
79
Future directions:
 
80
 
 
81
1) Replace the pickled files with a more generic serialization option (e.g. json)
 
82
2) Add methods to statically extend the mocks (e.g. method call return values)
 
83
3) Extend an existing framework, e.g. mox