python/mock-1.0.0/docs/patch.txt

Wed, 31 Dec 2014 06:55:50 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Wed, 31 Dec 2014 06:55:50 +0100
changeset 2
7e26c7da4463
permissions
-rw-r--r--

Added tag UPSTREAM_283F7C6 for changeset ca08bd8f51b2

     1 ==================
     2  Patch Decorators
     3 ==================
     6 .. currentmodule:: mock
     8 .. testsetup::
    10     class SomeClass(object):
    11         static_method = None
    12         class_method = None
    13         attribute = None
    15     sys.modules['package'] = package = Mock(name='package')
    16     sys.modules['package.module'] = package.module
    18     class TestCase(unittest2.TestCase):
    19         def run(self):
    20             result = unittest2.TestResult()
    21             super(unittest2.TestCase, self).run(result)
    22             assert result.wasSuccessful()
    24 .. testcleanup::
    26     patch.TEST_PREFIX = 'test'
    29 The patch decorators are used for patching objects only within the scope of
    30 the function they decorate. They automatically handle the unpatching for you,
    31 even if exceptions are raised. All of these functions can also be used in with
    32 statements or as class decorators.
    35 patch
    36 =====
    38 .. note::
    40     `patch` is straightforward to use. The key is to do the patching in the
    41     right namespace. See the section `where to patch`_.
    43 .. function:: patch(target, new=DEFAULT, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs)
    45     `patch` acts as a function decorator, class decorator or a context
    46     manager. Inside the body of the function or with statement, the `target`
    47     is patched with a `new` object. When the function/with statement exits
    48     the patch is undone.
    50     If `new` is omitted, then the target is replaced with a
    51     :class:`MagicMock`. If `patch` is used as a decorator and `new` is
    52     omitted, the created mock is passed in as an extra argument to the
    53     decorated function. If `patch` is used as a context manager the created
    54     mock is returned by the context manager.
    56     `target` should be a string in the form `'package.module.ClassName'`. The
    57     `target` is imported and the specified object replaced with the `new`
    58     object, so the `target` must be importable from the environment you are
    59     calling `patch` from. The target is imported when the decorated function
    60     is executed, not at decoration time.
    62     The `spec` and `spec_set` keyword arguments are passed to the `MagicMock`
    63     if patch is creating one for you.
    65     In addition you can pass `spec=True` or `spec_set=True`, which causes
    66     patch to pass in the object being mocked as the spec/spec_set object.
    68     `new_callable` allows you to specify a different class, or callable object,
    69     that will be called to create the `new` object. By default `MagicMock` is
    70     used.
    72     A more powerful form of `spec` is `autospec`. If you set `autospec=True`
    73     then the mock with be created with a spec from the object being replaced.
    74     All attributes of the mock will also have the spec of the corresponding
    75     attribute of the object being replaced. Methods and functions being mocked
    76     will have their arguments checked and will raise a `TypeError` if they are
    77     called with the wrong signature. For mocks
    78     replacing a class, their return value (the 'instance') will have the same
    79     spec as the class. See the :func:`create_autospec` function and
    80     :ref:`auto-speccing`.
    82     Instead of `autospec=True` you can pass `autospec=some_object` to use an
    83     arbitrary object as the spec instead of the one being replaced.
    85     By default `patch` will fail to replace attributes that don't exist. If
    86     you pass in `create=True`, and the attribute doesn't exist, patch will
    87     create the attribute for you when the patched function is called, and
    88     delete it again afterwards. This is useful for writing tests against
    89     attributes that your production code creates at runtime. It is off by by
    90     default because it can be dangerous. With it switched on you can write
    91     passing tests against APIs that don't actually exist!
    93     Patch can be used as a `TestCase` class decorator. It works by
    94     decorating each test method in the class. This reduces the boilerplate
    95     code when your test methods share a common patchings set. `patch` finds
    96     tests by looking for method names that start with `patch.TEST_PREFIX`.
    97     By default this is `test`, which matches the way `unittest` finds tests.
    98     You can specify an alternative prefix by setting `patch.TEST_PREFIX`.
   100     Patch can be used as a context manager, with the with statement. Here the
   101     patching applies to the indented block after the with statement. If you
   102     use "as" then the patched object will be bound to the name after the
   103     "as"; very useful if `patch` is creating a mock object for you.
   105     `patch` takes arbitrary keyword arguments. These will be passed to
   106     the `Mock` (or `new_callable`) on construction.
   108     `patch.dict(...)`, `patch.multiple(...)` and `patch.object(...)` are
   109     available for alternate use-cases.
   111 `patch` as function decorator, creating the mock for you and passing it into
   112 the decorated function:
   114 .. doctest::
   116     >>> @patch('__main__.SomeClass')
   117     ... def function(normal_argument, mock_class):
   118     ...     print mock_class is SomeClass
   119     ...
   120     >>> function(None)
   121     True
   124 Patching a class replaces the class with a `MagicMock` *instance*. If the
   125 class is instantiated in the code under test then it will be the
   126 :attr:`~Mock.return_value` of the mock that will be used.
   128 If the class is instantiated multiple times you could use
   129 :attr:`~Mock.side_effect` to return a new mock each time. Alternatively you
   130 can set the `return_value` to be anything you want.
   132 To configure return values on methods of *instances* on the patched class
   133 you must do this on the `return_value`. For example:
   135 .. doctest::
   137     >>> class Class(object):
   138     ...     def method(self):
   139     ...         pass
   140     ...
   141     >>> with patch('__main__.Class') as MockClass:
   142     ...     instance = MockClass.return_value
   143     ...     instance.method.return_value = 'foo'
   144     ...     assert Class() is instance
   145     ...     assert Class().method() == 'foo'
   146     ...
   148 If you use `spec` or `spec_set` and `patch` is replacing a *class*, then the
   149 return value of the created mock will have the same spec.
   151 .. doctest::
   153     >>> Original = Class
   154     >>> patcher = patch('__main__.Class', spec=True)
   155     >>> MockClass = patcher.start()
   156     >>> instance = MockClass()
   157     >>> assert isinstance(instance, Original)
   158     >>> patcher.stop()
   160 The `new_callable` argument is useful where you want to use an alternative
   161 class to the default :class:`MagicMock` for the created mock. For example, if
   162 you wanted a :class:`NonCallableMock` to be used:
   164 .. doctest::
   166     >>> thing = object()
   167     >>> with patch('__main__.thing', new_callable=NonCallableMock) as mock_thing:
   168     ...     assert thing is mock_thing
   169     ...     thing()
   170     ...
   171     Traceback (most recent call last):
   172       ...
   173     TypeError: 'NonCallableMock' object is not callable
   175 Another use case might be to replace an object with a `StringIO` instance:
   177 .. doctest::
   179     >>> from StringIO import StringIO
   180     >>> def foo():
   181     ...     print 'Something'
   182     ...
   183     >>> @patch('sys.stdout', new_callable=StringIO)
   184     ... def test(mock_stdout):
   185     ...     foo()
   186     ...     assert mock_stdout.getvalue() == 'Something\n'
   187     ...
   188     >>> test()
   190 When `patch` is creating a mock for you, it is common that the first thing
   191 you need to do is to configure the mock. Some of that configuration can be done
   192 in the call to patch. Any arbitrary keywords you pass into the call will be
   193 used to set attributes on the created mock:
   195 .. doctest::
   197     >>> patcher = patch('__main__.thing', first='one', second='two')
   198     >>> mock_thing = patcher.start()
   199     >>> mock_thing.first
   200     'one'
   201     >>> mock_thing.second
   202     'two'
   204 As well as attributes on the created mock attributes, like the
   205 :attr:`~Mock.return_value` and :attr:`~Mock.side_effect`, of child mocks can
   206 also be configured. These aren't syntactically valid to pass in directly as
   207 keyword arguments, but a dictionary with these as keys can still be expanded
   208 into a `patch` call using `**`:
   210 .. doctest::
   212     >>> config = {'method.return_value': 3, 'other.side_effect': KeyError}
   213     >>> patcher = patch('__main__.thing', **config)
   214     >>> mock_thing = patcher.start()
   215     >>> mock_thing.method()
   216     3
   217     >>> mock_thing.other()
   218     Traceback (most recent call last):
   219       ...
   220     KeyError
   223 patch.object
   224 ============
   226 .. function:: patch.object(target, attribute, new=DEFAULT, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs)
   228     patch the named member (`attribute`) on an object (`target`) with a mock
   229     object.
   231     `patch.object` can be used as a decorator, class decorator or a context
   232     manager. Arguments `new`, `spec`, `create`, `spec_set`, `autospec` and
   233     `new_callable` have the same meaning as for `patch`. Like `patch`,
   234     `patch.object` takes arbitrary keyword arguments for configuring the mock
   235     object it creates.
   237     When used as a class decorator `patch.object` honours `patch.TEST_PREFIX`
   238     for choosing which methods to wrap.
   240 You can either call `patch.object` with three arguments or two arguments. The
   241 three argument form takes the object to be patched, the attribute name and the
   242 object to replace the attribute with.
   244 When calling with the two argument form you omit the replacement object, and a
   245 mock is created for you and passed in as an extra argument to the decorated
   246 function:
   248 .. doctest::
   250     >>> @patch.object(SomeClass, 'class_method')
   251     ... def test(mock_method):
   252     ...     SomeClass.class_method(3)
   253     ...     mock_method.assert_called_with(3)
   254     ...
   255     >>> test()
   257 `spec`, `create` and the other arguments to `patch.object` have the same
   258 meaning as they do for `patch`.
   261 patch.dict
   262 ==========
   264 .. function:: patch.dict(in_dict, values=(), clear=False, **kwargs)
   266     Patch a dictionary, or dictionary like object, and restore the dictionary
   267     to its original state after the test.
   269     `in_dict` can be a dictionary or a mapping like container. If it is a
   270     mapping then it must at least support getting, setting and deleting items
   271     plus iterating over keys.
   273     `in_dict` can also be a string specifying the name of the dictionary, which
   274     will then be fetched by importing it.
   276     `values` can be a dictionary of values to set in the dictionary. `values`
   277     can also be an iterable of `(key, value)` pairs.
   279     If `clear` is True then the dictionary will be cleared before the new
   280     values are set.
   282     `patch.dict` can also be called with arbitrary keyword arguments to set
   283     values in the dictionary.
   285     `patch.dict` can be used as a context manager, decorator or class
   286     decorator. When used as a class decorator `patch.dict` honours
   287     `patch.TEST_PREFIX` for choosing which methods to wrap.
   289 `patch.dict` can be used to add members to a dictionary, or simply let a test
   290 change a dictionary, and ensure the dictionary is restored when the test
   291 ends.
   293 .. doctest::
   295     >>> from mock import patch
   296     >>> foo = {}
   297     >>> with patch.dict(foo, {'newkey': 'newvalue'}):
   298     ...     assert foo == {'newkey': 'newvalue'}
   299     ...
   300     >>> assert foo == {}
   302     >>> import os
   303     >>> with patch.dict('os.environ', {'newkey': 'newvalue'}):
   304     ...     print os.environ['newkey']
   305     ...
   306     newvalue
   307     >>> assert 'newkey' not in os.environ
   309 Keywords can be used in the `patch.dict` call to set values in the dictionary:
   311 .. doctest::
   313     >>> mymodule = MagicMock()
   314     >>> mymodule.function.return_value = 'fish'
   315     >>> with patch.dict('sys.modules', mymodule=mymodule):
   316     ...     import mymodule
   317     ...     mymodule.function('some', 'args')
   318     ...
   319     'fish'
   321 `patch.dict` can be used with dictionary like objects that aren't actually
   322 dictionaries. At the very minimum they must support item getting, setting,
   323 deleting and either iteration or membership test. This corresponds to the
   324 magic methods `__getitem__`, `__setitem__`, `__delitem__` and either
   325 `__iter__` or `__contains__`.
   327 .. doctest::
   329     >>> class Container(object):
   330     ...     def __init__(self):
   331     ...         self.values = {}
   332     ...     def __getitem__(self, name):
   333     ...         return self.values[name]
   334     ...     def __setitem__(self, name, value):
   335     ...         self.values[name] = value
   336     ...     def __delitem__(self, name):
   337     ...         del self.values[name]
   338     ...     def __iter__(self):
   339     ...         return iter(self.values)
   340     ...
   341     >>> thing = Container()
   342     >>> thing['one'] = 1
   343     >>> with patch.dict(thing, one=2, two=3):
   344     ...     assert thing['one'] == 2
   345     ...     assert thing['two'] == 3
   346     ...
   347     >>> assert thing['one'] == 1
   348     >>> assert list(thing) == ['one']
   351 patch.multiple
   352 ==============
   354 .. function:: patch.multiple(target, spec=None, create=False, spec_set=None, autospec=None, new_callable=None, **kwargs)
   356     Perform multiple patches in a single call. It takes the object to be
   357     patched (either as an object or a string to fetch the object by importing)
   358     and keyword arguments for the patches::
   360         with patch.multiple(settings, FIRST_PATCH='one', SECOND_PATCH='two'):
   361             ...
   363     Use :data:`DEFAULT` as the value if you want `patch.multiple` to create
   364     mocks for you. In this case the created mocks are passed into a decorated
   365     function by keyword, and a dictionary is returned when `patch.multiple` is
   366     used as a context manager.
   368     `patch.multiple` can be used as a decorator, class decorator or a context
   369     manager. The arguments `spec`, `spec_set`, `create`, `autospec` and
   370     `new_callable` have the same meaning as for `patch`. These arguments will
   371     be applied to *all* patches done by `patch.multiple`.
   373     When used as a class decorator `patch.multiple` honours `patch.TEST_PREFIX`
   374     for choosing which methods to wrap.
   376 If you want `patch.multiple` to create mocks for you, then you can use
   377 :data:`DEFAULT` as the value. If you use `patch.multiple` as a decorator
   378 then the created mocks are passed into the decorated function by keyword.
   380 .. doctest::
   382     >>> thing = object()
   383     >>> other = object()
   385     >>> @patch.multiple('__main__', thing=DEFAULT, other=DEFAULT)
   386     ... def test_function(thing, other):
   387     ...     assert isinstance(thing, MagicMock)
   388     ...     assert isinstance(other, MagicMock)
   389     ...
   390     >>> test_function()
   392 `patch.multiple` can be nested with other `patch` decorators, but put arguments
   393 passed by keyword *after* any of the standard arguments created by `patch`:
   395 .. doctest::
   397     >>> @patch('sys.exit')
   398     ... @patch.multiple('__main__', thing=DEFAULT, other=DEFAULT)
   399     ... def test_function(mock_exit, other, thing):
   400     ...     assert 'other' in repr(other)
   401     ...     assert 'thing' in repr(thing)
   402     ...     assert 'exit' in repr(mock_exit)
   403     ...
   404     >>> test_function()
   406 If `patch.multiple` is used as a context manager, the value returned by the
   407 context manger is a dictionary where created mocks are keyed by name:
   409 .. doctest::
   411     >>> with patch.multiple('__main__', thing=DEFAULT, other=DEFAULT) as values:
   412     ...     assert 'other' in repr(values['other'])
   413     ...     assert 'thing' in repr(values['thing'])
   414     ...     assert values['thing'] is thing
   415     ...     assert values['other'] is other
   416     ...
   419 .. _start-and-stop:
   421 patch methods: start and stop
   422 =============================
   424 All the patchers have `start` and `stop` methods. These make it simpler to do
   425 patching in `setUp` methods or where you want to do multiple patches without
   426 nesting decorators or with statements.
   428 To use them call `patch`, `patch.object` or `patch.dict` as normal and keep a
   429 reference to the returned `patcher` object. You can then call `start` to put
   430 the patch in place and `stop` to undo it.
   432 If you are using `patch` to create a mock for you then it will be returned by
   433 the call to `patcher.start`.
   435 .. doctest::
   437     >>> patcher = patch('package.module.ClassName')
   438     >>> from package import module
   439     >>> original = module.ClassName
   440     >>> new_mock = patcher.start()
   441     >>> assert module.ClassName is not original
   442     >>> assert module.ClassName is new_mock
   443     >>> patcher.stop()
   444     >>> assert module.ClassName is original
   445     >>> assert module.ClassName is not new_mock
   448 A typical use case for this might be for doing multiple patches in the `setUp`
   449 method of a `TestCase`:
   451 .. doctest::
   453     >>> class MyTest(TestCase):
   454     ...     def setUp(self):
   455     ...         self.patcher1 = patch('package.module.Class1')
   456     ...         self.patcher2 = patch('package.module.Class2')
   457     ...         self.MockClass1 = self.patcher1.start()
   458     ...         self.MockClass2 = self.patcher2.start()
   459     ...
   460     ...     def tearDown(self):
   461     ...         self.patcher1.stop()
   462     ...         self.patcher2.stop()
   463     ...
   464     ...     def test_something(self):
   465     ...         assert package.module.Class1 is self.MockClass1
   466     ...         assert package.module.Class2 is self.MockClass2
   467     ...
   468     >>> MyTest('test_something').run()
   470 .. caution::
   472     If you use this technique you must ensure that the patching is "undone" by
   473     calling `stop`. This can be fiddlier than you might think, because if an
   474     exception is raised in the setUp then tearDown is not called. `unittest2
   475     <http://pypi.python.org/pypi/unittest2>`_ cleanup functions make this
   476     easier.
   478     .. doctest::
   480         >>> class MyTest(TestCase):
   481         ...     def setUp(self):
   482         ...         patcher = patch('package.module.Class')
   483         ...         self.MockClass = patcher.start()
   484         ...         self.addCleanup(patcher.stop)
   485         ...
   486         ...     def test_something(self):
   487         ...         assert package.module.Class is self.MockClass
   488         ...
   489         >>> MyTest('test_something').run()
   491     As an added bonus you no longer need to keep a reference to the `patcher`
   492     object.
   494 It is also possible to stop all patches which have been started by using
   495 `patch.stopall`.
   497 .. function:: patch.stopall
   499     Stop all active patches. Only stops patches started with `start`.
   502 TEST_PREFIX
   503 ===========
   505 All of the patchers can be used as class decorators. When used in this way
   506 they wrap every test method on the class. The patchers recognise methods that
   507 start with `test` as being test methods. This is the same way that the
   508 `unittest.TestLoader` finds test methods by default.
   510 It is possible that you want to use a different prefix for your tests. You can
   511 inform the patchers of the different prefix by setting `patch.TEST_PREFIX`:
   513 .. doctest::
   515     >>> patch.TEST_PREFIX = 'foo'
   516     >>> value = 3
   517     >>>
   518     >>> @patch('__main__.value', 'not three')
   519     ... class Thing(object):
   520     ...     def foo_one(self):
   521     ...         print value
   522     ...     def foo_two(self):
   523     ...         print value
   524     ...
   525     >>>
   526     >>> Thing().foo_one()
   527     not three
   528     >>> Thing().foo_two()
   529     not three
   530     >>> value
   531     3
   534 Nesting Patch Decorators
   535 ========================
   537 If you want to perform multiple patches then you can simply stack up the
   538 decorators.
   540 You can stack up multiple patch decorators using this pattern:
   542 .. doctest::
   544     >>> @patch.object(SomeClass, 'class_method')
   545     ... @patch.object(SomeClass, 'static_method')
   546     ... def test(mock1, mock2):
   547     ...     assert SomeClass.static_method is mock1
   548     ...     assert SomeClass.class_method is mock2
   549     ...     SomeClass.static_method('foo')
   550     ...     SomeClass.class_method('bar')
   551     ...     return mock1, mock2
   552     ...
   553     >>> mock1, mock2 = test()
   554     >>> mock1.assert_called_once_with('foo')
   555     >>> mock2.assert_called_once_with('bar')
   558 Note that the decorators are applied from the bottom upwards. This is the
   559 standard way that Python applies decorators. The order of the created mocks
   560 passed into your test function matches this order.
   562 Like all context-managers patches can be nested using contextlib's nested
   563 function; *every* patching will appear in the tuple after "as":
   565 .. doctest::
   567     >>> from contextlib import nested
   568     >>> with nested(
   569     ...         patch('package.module.ClassName1'),
   570     ...         patch('package.module.ClassName2')
   571     ...     ) as (MockClass1, MockClass2):
   572     ...     assert package.module.ClassName1 is MockClass1
   573     ...     assert package.module.ClassName2 is MockClass2
   574     ...
   577 .. _where-to-patch:
   579 Where to patch
   580 ==============
   582 `patch` works by (temporarily) changing the object that a *name* points to with
   583 another one. There can be many names pointing to any individual object, so
   584 for patching to work you must ensure that you patch the name used by the system
   585 under test.
   587 The basic principle is that you patch where an object is *looked up*, which
   588 is not necessarily the same place as where it is defined. A couple of
   589 examples will help to clarify this.
   591 Imagine we have a project that we want to test with the following structure::
   593     a.py
   594         -> Defines SomeClass
   596     b.py
   597         -> from a import SomeClass
   598         -> some_function instantiates SomeClass
   600 Now we want to test `some_function` but we want to mock out `SomeClass` using
   601 `patch`. The problem is that when we import module b, which we will have to
   602 do then it imports `SomeClass` from module a. If we use `patch` to mock out
   603 `a.SomeClass` then it will have no effect on our test; module b already has a
   604 reference to the *real* `SomeClass` and it looks like our patching had no
   605 effect.
   607 The key is to patch out `SomeClass` where it is used (or where it is looked up
   608 ). In this case `some_function` will actually look up `SomeClass` in module b,
   609 where we have imported it. The patching should look like:
   611     `@patch('b.SomeClass')`
   613 However, consider the alternative scenario where instead of `from a import
   614 SomeClass` module b does `import a` and `some_function` uses `a.SomeClass`. Both
   615 of these import forms are common. In this case the class we want to patch is
   616 being looked up on the a module and so we have to patch `a.SomeClass` instead:
   618     `@patch('a.SomeClass')`
   621 Patching Descriptors and Proxy Objects
   622 ======================================
   624 Since version 0.6.0 both patch_ and patch.object_ have been able to correctly
   625 patch and restore descriptors: class methods, static methods and properties.
   626 You should patch these on the *class* rather than an instance.
   628 Since version 0.7.0 patch_ and patch.object_ work correctly with some objects
   629 that proxy attribute access, like the `django setttings object
   630 <http://www.voidspace.org.uk/python/weblog/arch_d7_2010_12_04.shtml#e1198>`_.
   632 .. note::
   634     In django `import settings` and `from django.conf import settings`
   635     return different objects. If you are using libraries / apps that do both you
   636     may have to patch both. Grrr...

mercurial