Lines Matching +full:helper +full:- +full:module +full:- +full:imports
1 :mod:`unittest.mock` --- getting started
10 .. _getting-started:
27 ----------
119 ... instance = module.Foo()
122 >>> with patch('module.Foo') as mock:
148 to child attributes of the mock - and also to their children.
176 >>> m.mock_calls[-1] == call.factory(important=False).deliver()
284 :ref:`async-iterators` through ``__aiter__``. The :attr:`~Mock.return_value`
301 :ref:`async-context-managers` through ``__aenter__`` and ``__aexit__``.
328 you refactor the first class, so that it no longer has ``some_method`` - then
356 you can use :ref:`auto-speccing <auto-speccing>`.
365 ----------------
371 read :ref:`where to patch <where-to-patch>`.
374 A common need in tests is to patch a class attribute or a module attribute,
375 for example patching a builtin or patching a class in a module to test that it
382 ``package.module.Class.attribute`` to specify the attribute you are patching. It
398 >>> @patch('package.module.attribute', sentinel.attribute)
400 ... from package.module import attribute
405 If you are patching a module (including :mod:`builtins`) then use :func:`patch`
415 The module name can be 'dotted', in the form ``package.module`` if needed::
417 >>> @patch('package.module.ClassName.attribute', sentinel.attribute)
419 ... from package.module import ClassName
450 ... @patch('package.module.ClassName1')
451 ... @patch('package.module.ClassName2')
453 ... self.assertIs(package.module.ClassName1, MockClass1)
454 ... self.assertIs(package.module.ClassName2, MockClass2)
496 .. _further-examples:
499 ----------------
542 object it returns is 'file-like', so we'll ensure that our response object
582 so I couldn't just monkey-patch out the static :meth:`date.today` method.
589 mock out the ``date`` class in the module under test. The :attr:`side_effect`
603 module that *uses* it. See :ref:`where to patch <where-to-patch>`.
608 algorithm as the code under test, which is a classic testing anti-pattern.
615 <https://williambert.online/2011/07/how-to-unit-testing-in-django-with-mocking-and-patching/>`_.
685 An alternative way of managing patches is to use the :ref:`start-and-stop`.
736 mock auto-created in exactly the same way as before. What it means though, is
791 The :data:`call` helper makes it easy to make assertions about these calls. You
843 mock methods for doing the assertion. Again a helper function sets this up for
937 With unittest ``cleanup`` functions and the :ref:`start-and-stop` we can
938 achieve the same effect without the nested indentation. A simple helper
1043 reason might be to add helper methods. Here's a silly example:
1061 [#]_. So if you're subclassing to add helper methods then they'll also be
1081 these "sub-mocks" for attributes and return values. You can prevent your
1097 .. [#] An exception to this rule are the non-callable mocks. Attributes use the
1098 callable variant because otherwise non-callable mocks couldn't have callable
1102 Mocking imports with patch.dict
1107 the module namespace that we can patch out.
1109 Generally local imports are to be avoided. They are sometimes done to prevent
1113 import (store the module as a class or module attribute and only do the import
1118 fetches an *object*, which need not be a module. Importing a module for the
1119 first time results in a module object being put in ``sys.modules``, so usually
1120 when you import something you get a module back. This need not be the case
1124 in :data:`sys.modules`. Any imports whilst this patch is active will fetch the mock.
1129 Here's an example that mocks out the 'fooble' module.
1144 This also works for the ``from module import name`` form:
1154 With slightly more work you can also mock package imports:
1157 >>> modules = {'package': mock, 'package.module': mock.module}
1159 ... from package.module import fooble
1162 <Mock name='mock.module.fooble()' id='...'>
1163 >>> mock.module.fooble.assert_called_once_with()
1321 <https://pyhamcrest.readthedocs.io/en/release-1.8/integration/#module-hamcrest.library.integration.…