| ================== |
| Patch Decorators |
| ================== |
| |
| |
| .. currentmodule:: mock |
| |
| .. testsetup:: |
| |
| class SomeClass(object): |
| static_method = None |
| class_method = None |
| attribute = None |
| |
| sys.modules['package'] = package = Mock(name='package') |
| sys.modules['package.module'] = package.module |
| |
| class TestCase(unittest2.TestCase): |
| def run(self): |
| result = unittest2.TestResult() |
| super(unittest2.TestCase, self).run(result) |
| assert result.wasSuccessful() |
| |
| .. testcleanup:: |
| |
| patch.TEST_PREFIX = 'test' |
| |
| |
| The patch decorators are used for patching objects only within the scope of |
| the function they decorate. They automatically handle the unpatching for you, |
| even if exceptions are raised. All of these functions can also be used in with |
| statements or as class decorators. |
| |
| |
| patch |
| ===== |
| |
| .. note:: |
| |
| `patch` is straightforward to use. The key is to do the patching in the |
| right namespace. See the section `where to patch`_. |
| |
| .. function:: patch(target, new=DEFAULT, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs) |
| |
| `patch` acts as a function decorator, class decorator or a context |
| manager. Inside the body of the function or with statement, the `target` |
| is patched with a `new` object. When the function/with statement exits |
| the patch is undone. |
| |
| If `new` is omitted, then the target is replaced with a |
| :class:`MagicMock`. If `patch` is used as a decorator and `new` is |
| omitted, the created mock is passed in as an extra argument to the |
| decorated function. If `patch` is used as a context manager the created |
| mock is returned by the context manager. |
| |
| `target` should be a string in the form `'package.module.ClassName'`. The |
| `target` is imported and the specified object replaced with the `new` |
| object, so the `target` must be importable from the environment you are |
| calling `patch` from. The target is imported when the decorated function |
| is executed, not at decoration time. |
| |
| The `spec` and `spec_set` keyword arguments are passed to the `MagicMock` |
| if patch is creating one for you. |
| |
| In addition you can pass `spec=True` or `spec_set=True`, which causes |
| patch to pass in the object being mocked as the spec/spec_set object. |
| |
| `new_callable` allows you to specify a different class, or callable object, |
| that will be called to create the `new` object. By default `MagicMock` is |
| used. |
| |
| A more powerful form of `spec` is `autospec`. If you set `autospec=True` |
| then the mock with be created with a spec from the object being replaced. |
| All attributes of the mock will also have the spec of the corresponding |
| attribute of the object being replaced. Methods and functions being mocked |
| will have their arguments checked and will raise a `TypeError` if they are |
| called with the wrong signature. For mocks |
| replacing a class, their return value (the 'instance') will have the same |
| spec as the class. See the :func:`create_autospec` function and |
| :ref:`auto-speccing`. |
| |
| Instead of `autospec=True` you can pass `autospec=some_object` to use an |
| arbitrary object as the spec instead of the one being replaced. |
| |
| By default `patch` will fail to replace attributes that don't exist. If |
| you pass in `create=True`, and the attribute doesn't exist, patch will |
| create the attribute for you when the patched function is called, and |
| delete it again afterwards. This is useful for writing tests against |
| attributes that your production code creates at runtime. It is off by by |
| default because it can be dangerous. With it switched on you can write |
| passing tests against APIs that don't actually exist! |
| |
| Patch can be used as a `TestCase` class decorator. It works by |
| decorating each test method in the class. This reduces the boilerplate |
| code when your test methods share a common patchings set. `patch` finds |
| tests by looking for method names that start with `patch.TEST_PREFIX`. |
| By default this is `test`, which matches the way `unittest` finds tests. |
| You can specify an alternative prefix by setting `patch.TEST_PREFIX`. |
| |
| Patch can be used as a context manager, with the with statement. Here the |
| patching applies to the indented block after the with statement. If you |
| use "as" then the patched object will be bound to the name after the |
| "as"; very useful if `patch` is creating a mock object for you. |
| |
| `patch` takes arbitrary keyword arguments. These will be passed to |
| the `Mock` (or `new_callable`) on construction. |
| |
| `patch.dict(...)`, `patch.multiple(...)` and `patch.object(...)` are |
| available for alternate use-cases. |
| |
| `patch` as function decorator, creating the mock for you and passing it into |
| the decorated function: |
| |
| .. doctest:: |
| |
| >>> @patch('__main__.SomeClass') |
| ... def function(normal_argument, mock_class): |
| ... print mock_class is SomeClass |
| ... |
| >>> function(None) |
| True |
| |
| |
| Patching a class replaces the class with a `MagicMock` *instance*. If the |
| class is instantiated in the code under test then it will be the |
| :attr:`~Mock.return_value` of the mock that will be used. |
| |
| If the class is instantiated multiple times you could use |
| :attr:`~Mock.side_effect` to return a new mock each time. Alternatively you |
| can set the `return_value` to be anything you want. |
| |
| To configure return values on methods of *instances* on the patched class |
| you must do this on the `return_value`. For example: |
| |
| .. doctest:: |
| |
| >>> class Class(object): |
| ... def method(self): |
| ... pass |
| ... |
| >>> with patch('__main__.Class') as MockClass: |
| ... instance = MockClass.return_value |
| ... instance.method.return_value = 'foo' |
| ... assert Class() is instance |
| ... assert Class().method() == 'foo' |
| ... |
| |
| If you use `spec` or `spec_set` and `patch` is replacing a *class*, then the |
| return value of the created mock will have the same spec. |
| |
| .. doctest:: |
| |
| >>> Original = Class |
| >>> patcher = patch('__main__.Class', spec=True) |
| >>> MockClass = patcher.start() |
| >>> instance = MockClass() |
| >>> assert isinstance(instance, Original) |
| >>> patcher.stop() |
| |
| The `new_callable` argument is useful where you want to use an alternative |
| class to the default :class:`MagicMock` for the created mock. For example, if |
| you wanted a :class:`NonCallableMock` to be used: |
| |
| .. doctest:: |
| |
| >>> thing = object() |
| >>> with patch('__main__.thing', new_callable=NonCallableMock) as mock_thing: |
| ... assert thing is mock_thing |
| ... thing() |
| ... |
| Traceback (most recent call last): |
| ... |
| TypeError: 'NonCallableMock' object is not callable |
| |
| Another use case might be to replace an object with a `StringIO` instance: |
| |
| .. doctest:: |
| |
| >>> from StringIO import StringIO |
| >>> def foo(): |
| ... print 'Something' |
| ... |
| >>> @patch('sys.stdout', new_callable=StringIO) |
| ... def test(mock_stdout): |
| ... foo() |
| ... assert mock_stdout.getvalue() == 'Something\n' |
| ... |
| >>> test() |
| |
| When `patch` is creating a mock for you, it is common that the first thing |
| you need to do is to configure the mock. Some of that configuration can be done |
| in the call to patch. Any arbitrary keywords you pass into the call will be |
| used to set attributes on the created mock: |
| |
| .. doctest:: |
| |
| >>> patcher = patch('__main__.thing', first='one', second='two') |
| >>> mock_thing = patcher.start() |
| >>> mock_thing.first |
| 'one' |
| >>> mock_thing.second |
| 'two' |
| |
| As well as attributes on the created mock attributes, like the |
| :attr:`~Mock.return_value` and :attr:`~Mock.side_effect`, of child mocks can |
| also be configured. These aren't syntactically valid to pass in directly as |
| keyword arguments, but a dictionary with these as keys can still be expanded |
| into a `patch` call using `**`: |
| |
| .. doctest:: |
| |
| >>> config = {'method.return_value': 3, 'other.side_effect': KeyError} |
| >>> patcher = patch('__main__.thing', **config) |
| >>> mock_thing = patcher.start() |
| >>> mock_thing.method() |
| 3 |
| >>> mock_thing.other() |
| Traceback (most recent call last): |
| ... |
| KeyError |
| |
| |
| patch.object |
| ============ |
| |
| .. function:: patch.object(target, attribute, new=DEFAULT, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs) |
| |
| patch the named member (`attribute`) on an object (`target`) with a mock |
| object. |
| |
| `patch.object` can be used as a decorator, class decorator or a context |
| manager. Arguments `new`, `spec`, `create`, `spec_set`, `autospec` and |
| `new_callable` have the same meaning as for `patch`. Like `patch`, |
| `patch.object` takes arbitrary keyword arguments for configuring the mock |
| object it creates. |
| |
| When used as a class decorator `patch.object` honours `patch.TEST_PREFIX` |
| for choosing which methods to wrap. |
| |
| You can either call `patch.object` with three arguments or two arguments. The |
| three argument form takes the object to be patched, the attribute name and the |
| object to replace the attribute with. |
| |
| When calling with the two argument form you omit the replacement object, and a |
| mock is created for you and passed in as an extra argument to the decorated |
| function: |
| |
| .. doctest:: |
| |
| >>> @patch.object(SomeClass, 'class_method') |
| ... def test(mock_method): |
| ... SomeClass.class_method(3) |
| ... mock_method.assert_called_with(3) |
| ... |
| >>> test() |
| |
| `spec`, `create` and the other arguments to `patch.object` have the same |
| meaning as they do for `patch`. |
| |
| |
| patch.dict |
| ========== |
| |
| .. function:: patch.dict(in_dict, values=(), clear=False, **kwargs) |
| |
| Patch a dictionary, or dictionary like object, and restore the dictionary |
| to its original state after the test. |
| |
| `in_dict` can be a dictionary or a mapping like container. If it is a |
| mapping then it must at least support getting, setting and deleting items |
| plus iterating over keys. |
| |
| `in_dict` can also be a string specifying the name of the dictionary, which |
| will then be fetched by importing it. |
| |
| `values` can be a dictionary of values to set in the dictionary. `values` |
| can also be an iterable of `(key, value)` pairs. |
| |
| If `clear` is True then the dictionary will be cleared before the new |
| values are set. |
| |
| `patch.dict` can also be called with arbitrary keyword arguments to set |
| values in the dictionary. |
| |
| `patch.dict` can be used as a context manager, decorator or class |
| decorator. When used as a class decorator `patch.dict` honours |
| `patch.TEST_PREFIX` for choosing which methods to wrap. |
| |
| `patch.dict` can be used to add members to a dictionary, or simply let a test |
| change a dictionary, and ensure the dictionary is restored when the test |
| ends. |
| |
| .. doctest:: |
| |
| >>> from mock import patch |
| >>> foo = {} |
| >>> with patch.dict(foo, {'newkey': 'newvalue'}): |
| ... assert foo == {'newkey': 'newvalue'} |
| ... |
| >>> assert foo == {} |
| |
| >>> import os |
| >>> with patch.dict('os.environ', {'newkey': 'newvalue'}): |
| ... print os.environ['newkey'] |
| ... |
| newvalue |
| >>> assert 'newkey' not in os.environ |
| |
| Keywords can be used in the `patch.dict` call to set values in the dictionary: |
| |
| .. doctest:: |
| |
| >>> mymodule = MagicMock() |
| >>> mymodule.function.return_value = 'fish' |
| >>> with patch.dict('sys.modules', mymodule=mymodule): |
| ... import mymodule |
| ... mymodule.function('some', 'args') |
| ... |
| 'fish' |
| |
| `patch.dict` can be used with dictionary like objects that aren't actually |
| dictionaries. At the very minimum they must support item getting, setting, |
| deleting and either iteration or membership test. This corresponds to the |
| magic methods `__getitem__`, `__setitem__`, `__delitem__` and either |
| `__iter__` or `__contains__`. |
| |
| .. doctest:: |
| |
| >>> class Container(object): |
| ... def __init__(self): |
| ... self.values = {} |
| ... def __getitem__(self, name): |
| ... return self.values[name] |
| ... def __setitem__(self, name, value): |
| ... self.values[name] = value |
| ... def __delitem__(self, name): |
| ... del self.values[name] |
| ... def __iter__(self): |
| ... return iter(self.values) |
| ... |
| >>> thing = Container() |
| >>> thing['one'] = 1 |
| >>> with patch.dict(thing, one=2, two=3): |
| ... assert thing['one'] == 2 |
| ... assert thing['two'] == 3 |
| ... |
| >>> assert thing['one'] == 1 |
| >>> assert list(thing) == ['one'] |
| |
| |
| patch.multiple |
| ============== |
| |
| .. function:: patch.multiple(target, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs) |
| |
| Perform multiple patches in a single call. It takes the object to be |
| patched (either as an object or a string to fetch the object by importing) |
| and keyword arguments for the patches:: |
| |
| with patch.multiple(settings, FIRST_PATCH='one', SECOND_PATCH='two'): |
| ... |
| |
| Use :data:`DEFAULT` as the value if you want `patch.multiple` to create |
| mocks for you. In this case the created mocks are passed into a decorated |
| function by keyword, and a dictionary is returned when `patch.multiple` is |
| used as a context manager. |
| |
| `patch.multiple` can be used as a decorator, class decorator or a context |
| manager. The arguments `spec`, `spec_set`, `create`, `autospec` and |
| `new_callable` have the same meaning as for `patch`. These arguments will |
| be applied to *all* patches done by `patch.multiple`. |
| |
| When used as a class decorator `patch.multiple` honours `patch.TEST_PREFIX` |
| for choosing which methods to wrap. |
| |
| If you want `patch.multiple` to create mocks for you, then you can use |
| :data:`DEFAULT` as the value. If you use `patch.multiple` as a decorator |
| then the created mocks are passed into the decorated function by keyword. |
| |
| .. doctest:: |
| |
| >>> thing = object() |
| >>> other = object() |
| |
| >>> @patch.multiple('__main__', thing=DEFAULT, other=DEFAULT) |
| ... def test_function(thing, other): |
| ... assert isinstance(thing, MagicMock) |
| ... assert isinstance(other, MagicMock) |
| ... |
| >>> test_function() |
| |
| `patch.multiple` can be nested with other `patch` decorators, but put arguments |
| passed by keyword *after* any of the standard arguments created by `patch`: |
| |
| .. doctest:: |
| |
| >>> @patch('sys.exit') |
| ... @patch.multiple('__main__', thing=DEFAULT, other=DEFAULT) |
| ... def test_function(mock_exit, other, thing): |
| ... assert 'other' in repr(other) |
| ... assert 'thing' in repr(thing) |
| ... assert 'exit' in repr(mock_exit) |
| ... |
| >>> test_function() |
| |
| If `patch.multiple` is used as a context manager, the value returned by the |
| context manger is a dictionary where created mocks are keyed by name: |
| |
| .. doctest:: |
| |
| >>> with patch.multiple('__main__', thing=DEFAULT, other=DEFAULT) as values: |
| ... assert 'other' in repr(values['other']) |
| ... assert 'thing' in repr(values['thing']) |
| ... assert values['thing'] is thing |
| ... assert values['other'] is other |
| ... |
| |
| |
| .. _start-and-stop: |
| |
| patch methods: start and stop |
| ============================= |
| |
| All the patchers have `start` and `stop` methods. These make it simpler to do |
| patching in `setUp` methods or where you want to do multiple patches without |
| nesting decorators or with statements. |
| |
| To use them call `patch`, `patch.object` or `patch.dict` as normal and keep a |
| reference to the returned `patcher` object. You can then call `start` to put |
| the patch in place and `stop` to undo it. |
| |
| If you are using `patch` to create a mock for you then it will be returned by |
| the call to `patcher.start`. |
| |
| .. doctest:: |
| |
| >>> patcher = patch('package.module.ClassName') |
| >>> from package import module |
| >>> original = module.ClassName |
| >>> new_mock = patcher.start() |
| >>> assert module.ClassName is not original |
| >>> assert module.ClassName is new_mock |
| >>> patcher.stop() |
| >>> assert module.ClassName is original |
| >>> assert module.ClassName is not new_mock |
| |
| |
| A typical use case for this might be for doing multiple patches in the `setUp` |
| method of a `TestCase`: |
| |
| .. doctest:: |
| |
| >>> class MyTest(TestCase): |
| ... def setUp(self): |
| ... self.patcher1 = patch('package.module.Class1') |
| ... self.patcher2 = patch('package.module.Class2') |
| ... self.MockClass1 = self.patcher1.start() |
| ... self.MockClass2 = self.patcher2.start() |
| ... |
| ... def tearDown(self): |
| ... self.patcher1.stop() |
| ... self.patcher2.stop() |
| ... |
| ... def test_something(self): |
| ... assert package.module.Class1 is self.MockClass1 |
| ... assert package.module.Class2 is self.MockClass2 |
| ... |
| >>> MyTest('test_something').run() |
| |
| .. caution:: |
| |
| If you use this technique you must ensure that the patching is "undone" by |
| calling `stop`. This can be fiddlier than you might think, because if an |
| exception is raised in the setUp then tearDown is not called. `unittest2 |
| <http://pypi.python.org/pypi/unittest2>`_ cleanup functions make this |
| easier. |
| |
| .. doctest:: |
| |
| >>> class MyTest(TestCase): |
| ... def setUp(self): |
| ... patcher = patch('package.module.Class') |
| ... self.MockClass = patcher.start() |
| ... self.addCleanup(patcher.stop) |
| ... |
| ... def test_something(self): |
| ... assert package.module.Class is self.MockClass |
| ... |
| >>> MyTest('test_something').run() |
| |
| As an added bonus you no longer need to keep a reference to the `patcher` |
| object. |
| |
| It is also possible to stop all patches which have been started by using |
| `patch.stopall`. |
| |
| .. function:: patch.stopall |
| |
| Stop all active patches. Only stops patches started with `start`. |
| |
| |
| TEST_PREFIX |
| =========== |
| |
| All of the patchers can be used as class decorators. When used in this way |
| they wrap every test method on the class. The patchers recognise methods that |
| start with `test` as being test methods. This is the same way that the |
| `unittest.TestLoader` finds test methods by default. |
| |
| It is possible that you want to use a different prefix for your tests. You can |
| inform the patchers of the different prefix by setting `patch.TEST_PREFIX`: |
| |
| .. doctest:: |
| |
| >>> patch.TEST_PREFIX = 'foo' |
| >>> value = 3 |
| >>> |
| >>> @patch('__main__.value', 'not three') |
| ... class Thing(object): |
| ... def foo_one(self): |
| ... print value |
| ... def foo_two(self): |
| ... print value |
| ... |
| >>> |
| >>> Thing().foo_one() |
| not three |
| >>> Thing().foo_two() |
| not three |
| >>> value |
| 3 |
| |
| |
| Nesting Patch Decorators |
| ======================== |
| |
| If you want to perform multiple patches then you can simply stack up the |
| decorators. |
| |
| You can stack up multiple patch decorators using this pattern: |
| |
| .. doctest:: |
| |
| >>> @patch.object(SomeClass, 'class_method') |
| ... @patch.object(SomeClass, 'static_method') |
| ... def test(mock1, mock2): |
| ... assert SomeClass.static_method is mock1 |
| ... assert SomeClass.class_method is mock2 |
| ... SomeClass.static_method('foo') |
| ... SomeClass.class_method('bar') |
| ... return mock1, mock2 |
| ... |
| >>> mock1, mock2 = test() |
| >>> mock1.assert_called_once_with('foo') |
| >>> mock2.assert_called_once_with('bar') |
| |
| |
| Note that the decorators are applied from the bottom upwards. This is the |
| standard way that Python applies decorators. The order of the created mocks |
| passed into your test function matches this order. |
| |
| Like all context-managers patches can be nested using contextlib's nested |
| function; *every* patching will appear in the tuple after "as": |
| |
| .. doctest:: |
| |
| >>> from contextlib import nested |
| >>> with nested( |
| ... patch('package.module.ClassName1'), |
| ... patch('package.module.ClassName2') |
| ... ) as (MockClass1, MockClass2): |
| ... assert package.module.ClassName1 is MockClass1 |
| ... assert package.module.ClassName2 is MockClass2 |
| ... |
| |
| |
| .. _where-to-patch: |
| |
| Where to patch |
| ============== |
| |
| `patch` works by (temporarily) changing the object that a *name* points to with |
| another one. There can be many names pointing to any individual object, so |
| for patching to work you must ensure that you patch the name used by the system |
| under test. |
| |
| The basic principle is that you patch where an object is *looked up*, which |
| is not necessarily the same place as where it is defined. A couple of |
| examples will help to clarify this. |
| |
| Imagine we have a project that we want to test with the following structure:: |
| |
| a.py |
| -> Defines SomeClass |
| |
| b.py |
| -> from a import SomeClass |
| -> some_function instantiates SomeClass |
| |
| Now we want to test `some_function` but we want to mock out `SomeClass` using |
| `patch`. The problem is that when we import module b, which we will have to |
| do then it imports `SomeClass` from module a. If we use `patch` to mock out |
| `a.SomeClass` then it will have no effect on our test; module b already has a |
| reference to the *real* `SomeClass` and it looks like our patching had no |
| effect. |
| |
| The key is to patch out `SomeClass` where it is used (or where it is looked up |
| ). In this case `some_function` will actually look up `SomeClass` in module b, |
| where we have imported it. The patching should look like: |
| |
| `@patch('b.SomeClass')` |
| |
| However, consider the alternative scenario where instead of `from a import |
| SomeClass` module b does `import a` and `some_function` uses `a.SomeClass`. Both |
| of these import forms are common. In this case the class we want to patch is |
| being looked up on the a module and so we have to patch `a.SomeClass` instead: |
| |
| `@patch('a.SomeClass')` |
| |
| |
| Patching Descriptors and Proxy Objects |
| ====================================== |
| |
| Since version 0.6.0 both patch_ and patch.object_ have been able to correctly |
| patch and restore descriptors: class methods, static methods and properties. |
| You should patch these on the *class* rather than an instance. |
| |
| Since version 0.7.0 patch_ and patch.object_ work correctly with some objects |
| that proxy attribute access, like the `django setttings object |
| <http://www.voidspace.org.uk/python/weblog/arch_d7_2010_12_04.shtml#e1198>`_. |
| |
| .. note:: |
| |
| In django `import settings` and `from django.conf import settings` |
| return different objects. If you are using libraries / apps that do both you |
| may have to patch both. Grrr... |