1
0
Fork 0
python-docs-fr/library/unittest.mock.po

2138 lines
74 KiB
Plaintext
Raw Normal View History

2016-10-30 09:46:26 +00:00
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2016, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.6\n"
"Report-Msgid-Bugs-To: \n"
2017-04-02 20:14:06 +00:00
"POT-Creation-Date: 2017-04-02 22:11+0200\n"
2016-10-30 09:46:26 +00:00
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
2017-05-23 22:40:56 +00:00
"Language: fr\n"
2016-10-30 09:46:26 +00:00
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../Doc/library/unittest.mock.rst:3
msgid ":mod:`unittest.mock` --- mock object library"
msgstr ""
#: ../Doc/library/unittest.mock.rst:13
msgid "**Source code:** :source:`Lib/unittest/mock.py`"
msgstr ""
#: ../Doc/library/unittest.mock.rst:17
msgid ""
":mod:`unittest.mock` is a library for testing in Python. It allows you to "
"replace parts of your system under test with mock objects and make "
"assertions about how they have been used."
msgstr ""
#: ../Doc/library/unittest.mock.rst:21
msgid ""
":mod:`unittest.mock` provides a core :class:`Mock` class removing the need "
"to create a host of stubs throughout your test suite. After performing an "
"action, you can make assertions about which methods / attributes were used "
"and arguments they were called with. You can also specify return values and "
"set needed attributes in the normal way."
msgstr ""
#: ../Doc/library/unittest.mock.rst:27
msgid ""
"Additionally, mock provides a :func:`patch` decorator that handles patching "
"module and class level attributes within the scope of a test, along with :"
"const:`sentinel` for creating unique objects. See the `quick guide`_ for "
"some examples of how to use :class:`Mock`, :class:`MagicMock` and :func:"
"`patch`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:33
msgid ""
"Mock is very easy to use and is designed for use with :mod:`unittest`. Mock "
"is based on the 'action -> assertion' pattern instead of 'record -> replay' "
"used by many mocking frameworks."
msgstr ""
#: ../Doc/library/unittest.mock.rst:37
msgid ""
"There is a backport of :mod:`unittest.mock` for earlier versions of Python, "
"available as `mock on PyPI <https://pypi.python.org/pypi/mock>`_."
msgstr ""
#: ../Doc/library/unittest.mock.rst:42
msgid "Quick Guide"
msgstr ""
#: ../Doc/library/unittest.mock.rst:44
msgid ""
":class:`Mock` and :class:`MagicMock` objects create all attributes and "
"methods as you access them and store details of how they have been used. You "
"can configure them, to specify return values or limit what attributes are "
"available, and then make assertions about how they have been used:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:56
msgid ""
":attr:`side_effect` allows you to perform side effects, including raising an "
"exception when a mock is called:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:76
msgid ""
"Mock has many other ways you can configure it and control its behaviour. For "
"example the *spec* argument configures the mock to take its specification "
"from another object. Attempting to access attributes or methods on the mock "
"that don't exist on the spec will fail with an :exc:`AttributeError`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:81
msgid ""
"The :func:`patch` decorator / context manager makes it easy to mock classes "
"or objects in a module under test. The object you specify will be replaced "
"with a mock (or other object) during the test and restored when the test "
"ends:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:100
msgid ""
"When you nest patch decorators the mocks are passed in to the decorated "
"function in the same order they applied (the normal *python* order that "
"decorators are applied). This means from the bottom up, so in the example "
"above the mock for ``module.ClassName1`` is passed in first."
msgstr ""
#: ../Doc/library/unittest.mock.rst:105
msgid ""
"With :func:`patch` it matters that you patch objects in the namespace where "
"they are looked up. This is normally straightforward, but for a quick guide "
"read :ref:`where to patch <where-to-patch>`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:109
msgid ""
"As well as a decorator :func:`patch` can be used as a context manager in a "
"with statement:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:119
msgid ""
"There is also :func:`patch.dict` for setting values in a dictionary just "
"during a scope and restoring the dictionary to its original state when the "
"test ends:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:130
msgid ""
"Mock supports the mocking of Python :ref:`magic methods <magic-methods>`. "
"The easiest way of using magic methods is with the :class:`MagicMock` class. "
"It allows you to do things like:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:140
msgid ""
"Mock allows you to assign functions (or other Mock instances) to magic "
"methods and they will be called appropriately. The :class:`MagicMock` class "
"is just a Mock variant that has all of the magic methods pre-created for you "
"(well, all the useful ones anyway)."
msgstr ""
#: ../Doc/library/unittest.mock.rst:145
msgid ""
"The following is an example of using magic methods with the ordinary Mock "
"class:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:153
msgid ""
"For ensuring that the mock objects in your tests have the same api as the "
"objects they are replacing, you can use :ref:`auto-speccing <auto-"
"speccing>`. Auto-speccing can be done through the *autospec* argument to "
"patch, or the :func:`create_autospec` function. Auto-speccing creates mock "
"objects that have the same attributes and methods as the objects they are "
"replacing, and any functions and methods (including constructors) have the "
"same call signature as the real object."
msgstr ""
#: ../Doc/library/unittest.mock.rst:161
msgid ""
"This ensures that your mocks will fail in the same way as your production "
"code if they are used incorrectly:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:177
msgid ""
":func:`create_autospec` can also be used on classes, where it copies the "
"signature of the ``__init__`` method, and on callable objects where it "
"copies the signature of the ``__call__`` method."
msgstr ""
#: ../Doc/library/unittest.mock.rst:184
msgid "The Mock Class"
msgstr ""
#: ../Doc/library/unittest.mock.rst:187
msgid ""
":class:`Mock` is a flexible mock object intended to replace the use of stubs "
"and test doubles throughout your code. Mocks are callable and create "
"attributes as new mocks when you access them [#]_. Accessing the same "
"attribute will always return the same mock. Mocks record how you use them, "
"allowing you to make assertions about what your code has done to them."
msgstr ""
#: ../Doc/library/unittest.mock.rst:193
msgid ""
":class:`MagicMock` is a subclass of :class:`Mock` with all the magic methods "
"pre-created and ready to use. There are also non-callable variants, useful "
"when you are mocking out objects that aren't callable: :class:"
"`NonCallableMock` and :class:`NonCallableMagicMock`"
msgstr ""
#: ../Doc/library/unittest.mock.rst:198
msgid ""
"The :func:`patch` decorators makes it easy to temporarily replace classes in "
"a particular module with a :class:`Mock` object. By default :func:`patch` "
"will create a :class:`MagicMock` for you. You can specify an alternative "
"class of :class:`Mock` using the *new_callable* argument to :func:`patch`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:206
msgid ""
"Create a new :class:`Mock` object. :class:`Mock` takes several optional "
"arguments that specify the behaviour of the Mock object:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:209
msgid ""
"*spec*: This can be either a list of strings or an existing object (a class "
"or instance) that acts as the specification for the mock object. If you pass "
"in an object then a list of strings is formed by calling dir on the object "
"(excluding unsupported magic attributes and methods). Accessing any "
"attribute not in this list will raise an :exc:`AttributeError`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:215
msgid ""
"If *spec* is an object (rather than a list of strings) then :attr:`~instance."
"__class__` returns the class of the spec object. This allows mocks to pass :"
"func:`isinstance` tests."
msgstr ""
#: ../Doc/library/unittest.mock.rst:219
msgid ""
"*spec_set*: A stricter variant of *spec*. If used, attempting to *set* or "
"get an attribute on the mock that isn't on the object passed as *spec_set* "
"will raise an :exc:`AttributeError`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:223
msgid ""
"*side_effect*: A function to be called whenever the Mock is called. See the :"
"attr:`~Mock.side_effect` attribute. Useful for raising exceptions or "
"dynamically changing return values. The function is called with the same "
"arguments as the mock, and unless it returns :data:`DEFAULT`, the return "
"value of this function is used as the return value."
msgstr ""
#: ../Doc/library/unittest.mock.rst:229
msgid ""
"Alternatively *side_effect* can be an exception class or instance. In this "
"case the exception will be raised when the mock is called."
msgstr ""
#: ../Doc/library/unittest.mock.rst:232
msgid ""
"If *side_effect* is an iterable then each call to the mock will return the "
"next value from the iterable."
msgstr ""
#: ../Doc/library/unittest.mock.rst:235
msgid "A *side_effect* can be cleared by setting it to ``None``."
msgstr ""
#: ../Doc/library/unittest.mock.rst:237
msgid ""
"*return_value*: The value returned when the mock is called. By default this "
"is a new Mock (created on first access). See the :attr:`return_value` "
"attribute."
msgstr ""
#: ../Doc/library/unittest.mock.rst:241
msgid ""
"*unsafe*: By default if any attribute starts with *assert* or *assret* will "
"raise an :exc:`AttributeError`. Passing ``unsafe=True`` will allow access to "
"these attributes."
msgstr ""
#: ../Doc/library/unittest.mock.rst:247
msgid ""
"*wraps*: Item for the mock object to wrap. If *wraps* is not ``None`` then "
"calling the Mock will pass the call through to the wrapped object (returning "
"the real result). Attribute access on the mock will return a Mock object "
"that wraps the corresponding attribute of the wrapped object (so attempting "
"to access an attribute that doesn't exist will raise an :exc:"
"`AttributeError`)."
msgstr ""
#: ../Doc/library/unittest.mock.rst:254
msgid ""
"If the mock has an explicit *return_value* set then calls are not passed to "
"the wrapped object and the *return_value* is returned instead."
msgstr ""
#: ../Doc/library/unittest.mock.rst:257
msgid ""
"*name*: If the mock has a name then it will be used in the repr of the mock. "
"This can be useful for debugging. The name is propagated to child mocks."
msgstr ""
#: ../Doc/library/unittest.mock.rst:261
msgid ""
"Mocks can also be called with arbitrary keyword arguments. These will be "
"used to set attributes on the mock after it is created. See the :meth:"
"`configure_mock` method for details."
msgstr ""
#: ../Doc/library/unittest.mock.rst:267
msgid "Assert that the mock was called at least once."
msgstr ""
#: ../Doc/library/unittest.mock.rst:278
msgid "Assert that the mock was called exactly once."
msgstr ""
#: ../Doc/library/unittest.mock.rst:296
msgid ""
"This method is a convenient way of asserting that calls are made in a "
"particular way:"
msgstr ""
#: ../Doc/library/unittest.mock.rst:306
msgid ""
2017-04-02 20:14:06 +00:00
"Assert that the mock was called exactly once and that that call was with the "
"specified arguments."
2016-10-30 09:46:26 +00:00
msgstr ""
#: ../Doc/library/unittest.mock.rst:321
msgid "assert the mock has been called with the specified arguments."
msgstr ""
#: ../Doc/library/unittest.mock.rst:323
msgid ""
"The assert passes if the mock has *ever* been called, unlike :meth:"
"`assert_called_with` and :meth:`assert_called_once_with` that only pass if "
2017-04-02 20:14:06 +00:00
"the call is the most recent one, and in the case of :meth:"
"`assert_called_once_with` it must also be the only call."
2016-10-30 09:46:26 +00:00
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:336
2016-10-30 09:46:26 +00:00
msgid ""
"assert the mock has been called with the specified calls. The :attr:"
"`mock_calls` list is checked for the calls."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:339
2016-10-30 09:46:26 +00:00
msgid ""
"If *any_order* is false (the default) then the calls must be sequential. "
"There can be extra calls before or after the specified calls."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:343
2016-10-30 09:46:26 +00:00
msgid ""
"If *any_order* is true then the calls can be in any order, but they must all "
"appear in :attr:`mock_calls`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:358
2016-10-30 09:46:26 +00:00
msgid "Assert the mock was never called."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:373
2016-10-30 09:46:26 +00:00
msgid "The reset_mock method resets all the call attributes on a mock object:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:383
2016-10-30 09:46:26 +00:00
msgid "Added two keyword only argument to the reset_mock function."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:386
2016-10-30 09:46:26 +00:00
msgid ""
"This can be useful where you want to make a series of assertions that reuse "
"the same object. Note that :meth:`reset_mock` *doesn't* clear the return "
"value, :attr:`side_effect` or any child attributes you have set using normal "
"assignment by default. In case you want to reset *return_value* or :attr:"
"`side_effect`, then pass the corresponding parameter as ``True``. Child "
"mocks and the return value mock (if any) are reset as well."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:394
2016-10-30 09:46:26 +00:00
msgid "*return_value*, and :attr:`side_effect` are keyword only argument."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:400
2016-10-30 09:46:26 +00:00
msgid ""
"Add a spec to a mock. *spec* can either be an object or a list of strings. "
"Only attributes on the *spec* can be fetched as attributes from the mock."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:404
2016-10-30 09:46:26 +00:00
msgid "If *spec_set* is true then only attributes on the spec can be set."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:409
2016-10-30 09:46:26 +00:00
msgid ""
"Attach a mock as an attribute of this one, replacing its name and parent. "
"Calls to the attached mock will be recorded in the :attr:`method_calls` and :"
"attr:`mock_calls` attributes of this one."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:416
2016-10-30 09:46:26 +00:00
msgid "Set attributes on the mock through keyword arguments."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:418
2016-10-30 09:46:26 +00:00
msgid ""
"Attributes plus return values and side effects can be set on child mocks "
"using standard dot notation and unpacking a dictionary in the method call:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:432
2016-10-30 09:46:26 +00:00
msgid "The same thing can be achieved in the constructor call to mocks:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:445
2016-10-30 09:46:26 +00:00
msgid ""
":meth:`configure_mock` exists to make it easier to do configuration after "
"the mock has been created."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:451
2016-10-30 09:46:26 +00:00
msgid ""
":class:`Mock` objects limit the results of ``dir(some_mock)`` to useful "
"results. For mocks with a *spec* this includes all the permitted attributes "
"for the mock."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:455
2016-10-30 09:46:26 +00:00
msgid ""
"See :data:`FILTER_DIR` for what this filtering does, and how to switch it "
"off."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:461
2016-10-30 09:46:26 +00:00
msgid ""
"Create the child mocks for attributes and return value. By default child "
"mocks will be the same type as the parent. Subclasses of Mock may want to "
"override this to customize the way child mocks are made."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:466
2016-10-30 09:46:26 +00:00
msgid ""
"For non-callable mocks the callable variant will be used (rather than any "
"custom subclass)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:472
2016-10-30 09:46:26 +00:00
msgid "A boolean representing whether or not the mock object has been called:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:483
2016-10-30 09:46:26 +00:00
msgid "An integer telling you how many times the mock object has been called:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:496
2016-10-30 09:46:26 +00:00
msgid "Set this to configure the value returned by calling the mock:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:503
2016-10-30 09:46:26 +00:00
msgid ""
"The default return value is a mock object and you can configure it in the "
"normal way:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:512
2016-10-30 09:46:26 +00:00
msgid ":attr:`return_value` can also be set in the constructor:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:523
2016-10-30 09:46:26 +00:00
msgid ""
"This can either be a function to be called when the mock is called, an "
"iterable or an exception (class or instance) to be raised."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:526
2016-10-30 09:46:26 +00:00
msgid ""
"If you pass in a function it will be called with same arguments as the mock "
"and unless the function returns the :data:`DEFAULT` singleton the call to "
"the mock will then return whatever the function returns. If the function "
"returns :data:`DEFAULT` then the mock will return its normal value (from "
"the :attr:`return_value`)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:532
2016-10-30 09:46:26 +00:00
msgid ""
"If you pass in an iterable, it is used to retrieve an iterator which must "
"yield a value on every call. This value can either be an exception instance "
"to be raised, or a value to be returned from the call to the mock (:data:"
"`DEFAULT` handling is identical to the function case)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:537
2016-10-30 09:46:26 +00:00
msgid ""
"An example of a mock that raises an exception (to test exception handling of "
"an API):"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:547
2016-10-30 09:46:26 +00:00
msgid "Using :attr:`side_effect` to return a sequence of values:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:554
2016-10-30 09:46:26 +00:00
msgid "Using a callable:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:564
2016-10-30 09:46:26 +00:00
msgid ""
":attr:`side_effect` can be set in the constructor. Here's an example that "
"adds one to the value the mock is called with and returns it:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:574
2016-10-30 09:46:26 +00:00
msgid "Setting :attr:`side_effect` to ``None`` clears it:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:588
2016-10-30 09:46:26 +00:00
msgid ""
"This is either ``None`` (if the mock hasn't been called), or the arguments "
"that the mock was last called with. This will be in the form of a tuple: the "
"first member is any ordered arguments the mock was called with (or an empty "
"tuple) and the second member is any keyword arguments (or an empty "
"dictionary)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:611
2016-10-30 09:46:26 +00:00
msgid ""
":attr:`call_args`, along with members of the lists :attr:`call_args_list`, :"
"attr:`method_calls` and :attr:`mock_calls` are :data:`call` objects. These "
"are tuples, so they can be unpacked to get at the individual arguments and "
"make more complex assertions. See :ref:`calls as tuples <calls-as-tuples>`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:620
2016-10-30 09:46:26 +00:00
msgid ""
"This is a list of all the calls made to the mock object in sequence (so the "
"length of the list is the number of times it has been called). Before any "
"calls have been made it is an empty list. The :data:`call` object can be "
"used for conveniently constructing lists of calls to compare with :attr:"
"`call_args_list`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:636
2016-10-30 09:46:26 +00:00
msgid ""
"Members of :attr:`call_args_list` are :data:`call` objects. These can be "
"unpacked as tuples to get at the individual arguments. See :ref:`calls as "
"tuples <calls-as-tuples>`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:643
2016-10-30 09:46:26 +00:00
msgid ""
"As well as tracking calls to themselves, mocks also track calls to methods "
"and attributes, and *their* methods and attributes:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:654
2016-10-30 09:46:26 +00:00
msgid ""
"Members of :attr:`method_calls` are :data:`call` objects. These can be "
"unpacked as tuples to get at the individual arguments. See :ref:`calls as "
"tuples <calls-as-tuples>`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:661
2016-10-30 09:46:26 +00:00
msgid ""
":attr:`mock_calls` records *all* calls to the mock object, its methods, "
"magic methods *and* return value mocks."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:679
2016-10-30 09:46:26 +00:00
msgid ""
"Members of :attr:`mock_calls` are :data:`call` objects. These can be "
"unpacked as tuples to get at the individual arguments. See :ref:`calls as "
"tuples <calls-as-tuples>`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:686
2016-10-30 09:46:26 +00:00
msgid ""
"Normally the :attr:`__class__` attribute of an object will return its type. "
"For a mock object with a :attr:`spec`, ``__class__`` returns the spec class "
"instead. This allows mock objects to pass :func:`isinstance` tests for the "
"object they are replacing / masquerading as:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:695
2016-10-30 09:46:26 +00:00
msgid ""
":attr:`__class__` is assignable to, this allows a mock to pass an :func:"
"`isinstance` check without forcing you to use a spec:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:705
2016-10-30 09:46:26 +00:00
msgid ""
"A non-callable version of :class:`Mock`. The constructor parameters have the "
"same meaning of :class:`Mock`, with the exception of *return_value* and "
"*side_effect* which have no meaning on a non-callable mock."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:709
2016-10-30 09:46:26 +00:00
msgid ""
"Mock objects that use a class or an instance as a :attr:`spec` or :attr:"
"`spec_set` are able to pass :func:`isinstance` tests:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:719
2016-10-30 09:46:26 +00:00
msgid ""
"The :class:`Mock` classes have support for mocking magic methods. See :ref:"
"`magic methods <magic-methods>` for the full details."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:722
2016-10-30 09:46:26 +00:00
msgid ""
"The mock classes and the :func:`patch` decorators all take arbitrary keyword "
"arguments for configuration. For the :func:`patch` decorators the keywords "
"are passed to the constructor of the mock being created. The keyword "
"arguments are for configuring attributes of the mock:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:733
2016-10-30 09:46:26 +00:00
msgid ""
"The return value and side effect of child mocks can be set in the same way, "
"using dotted notation. As you can't use dotted names directly in a call you "
"have to create a dictionary and unpack it using ``**``:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:748
2016-10-30 09:46:26 +00:00
msgid ""
"A callable mock which was created with a *spec* (or a *spec_set*) will "
"introspect the specification object's signature when matching calls to the "
"mock. Therefore, it can match the actual call's arguments regardless of "
"whether they were passed positionally or by name::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:761
2016-10-30 09:46:26 +00:00
msgid ""
"This applies to :meth:`~Mock.assert_called_with`, :meth:`~Mock."
"assert_called_once_with`, :meth:`~Mock.assert_has_calls` and :meth:`~Mock."
"assert_any_call`. When :ref:`auto-speccing`, it will also apply to method "
"calls on the mock object."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:766
2016-10-30 09:46:26 +00:00
msgid "Added signature introspection on specced and autospecced mock objects."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:772
2016-10-30 09:46:26 +00:00
msgid ""
"A mock intended to be used as a property, or other descriptor, on a class. :"
"class:`PropertyMock` provides :meth:`__get__` and :meth:`__set__` methods so "
"you can specify a return value when it is fetched."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:776
2016-10-30 09:46:26 +00:00
msgid ""
"Fetching a :class:`PropertyMock` instance from an object calls the mock, "
"with no args. Setting it calls the mock with the value being set."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:797
2016-10-30 09:46:26 +00:00
msgid ""
"Because of the way mock attributes are stored you can't directly attach a :"
"class:`PropertyMock` to a mock object. Instead you can attach it to the mock "
"type object::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:810
2016-10-30 09:46:26 +00:00
msgid "Calling"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:812
2016-10-30 09:46:26 +00:00
msgid ""
"Mock objects are callable. The call will return the value set as the :attr:"
"`~Mock.return_value` attribute. The default return value is a new Mock "
"object; it is created the first time the return value is accessed (either "
"explicitly or by calling the Mock) - but it is stored and the same one "
"returned each time."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:818
2016-10-30 09:46:26 +00:00
msgid ""
"Calls made to the object will be recorded in the attributes like :attr:"
"`~Mock.call_args` and :attr:`~Mock.call_args_list`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:821
2016-10-30 09:46:26 +00:00
msgid ""
"If :attr:`~Mock.side_effect` is set then it will be called after the call "
"has been recorded, so if :attr:`side_effect` raises an exception the call is "
"still recorded."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:825
2016-10-30 09:46:26 +00:00
msgid ""
"The simplest way to make a mock raise an exception when called is to make :"
"attr:`~Mock.side_effect` an exception class or instance:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:843
2016-10-30 09:46:26 +00:00
msgid ""
"If :attr:`side_effect` is a function then whatever that function returns is "
"what calls to the mock return. The :attr:`side_effect` function is called "
"with the same arguments as the mock. This allows you to vary the return "
"value of the call dynamically, based on the input:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:859
2016-10-30 09:46:26 +00:00
msgid ""
"If you want the mock to still return the default return value (a new mock), "
"or any set return value, then there are two ways of doing this. Either "
"return :attr:`mock.return_value` from inside :attr:`side_effect`, or return :"
"data:`DEFAULT`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:878
2016-10-30 09:46:26 +00:00
msgid ""
"To remove a :attr:`side_effect`, and return to the default behaviour, set "
"the :attr:`side_effect` to ``None``:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:892
2016-10-30 09:46:26 +00:00
msgid ""
"The :attr:`side_effect` can also be any iterable object. Repeated calls to "
"the mock will return values from the iterable (until the iterable is "
"exhausted and a :exc:`StopIteration` is raised):"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:908
2016-10-30 09:46:26 +00:00
msgid ""
"If any members of the iterable are exceptions they will be raised instead of "
"returned::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:926
2016-10-30 09:46:26 +00:00
msgid "Deleting Attributes"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:928
2016-10-30 09:46:26 +00:00
msgid ""
"Mock objects create attributes on demand. This allows them to pretend to be "
"objects of any type."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:931
2016-10-30 09:46:26 +00:00
msgid ""
"You may want a mock object to return ``False`` to a :func:`hasattr` call, or "
"raise an :exc:`AttributeError` when an attribute is fetched. You can do this "
"by providing an object as a :attr:`spec` for a mock, but that isn't always "
"convenient."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:935
2016-10-30 09:46:26 +00:00
msgid ""
"You \"block\" attributes by deleting them. Once deleted, accessing an "
"attribute will raise an :exc:`AttributeError`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:952
2016-10-30 09:46:26 +00:00
msgid "Mock names and the name attribute"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:954
2016-10-30 09:46:26 +00:00
msgid ""
"Since \"name\" is an argument to the :class:`Mock` constructor, if you want "
"your mock object to have a \"name\" attribute you can't just pass it in at "
"creation time. There are two alternatives. One option is to use :meth:`~Mock."
"configure_mock`::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:964
2016-10-30 09:46:26 +00:00
msgid ""
"A simpler option is to simply set the \"name\" attribute after mock "
"creation::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:971
2016-10-30 09:46:26 +00:00
msgid "Attaching Mocks as Attributes"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:973
2016-10-30 09:46:26 +00:00
msgid ""
"When you attach a mock as an attribute of another mock (or as the return "
"value) it becomes a \"child\" of that mock. Calls to the child are recorded "
"in the :attr:`~Mock.method_calls` and :attr:`~Mock.mock_calls` attributes of "
"the parent. This is useful for configuring child mocks and then attaching "
"them to the parent, or for attaching mocks to a parent that records all "
"calls to the children and allows you to make assertions about the order of "
"calls between mocks:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:991
2016-10-30 09:46:26 +00:00
msgid ""
"The exception to this is if the mock has a name. This allows you to prevent "
"the \"parenting\" if for some reason you don't want it to happen."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1002
2016-10-30 09:46:26 +00:00
msgid ""
"Mocks created for you by :func:`patch` are automatically given names. To "
"attach mocks that have names to a parent you use the :meth:`~Mock."
"attach_mock` method:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1020
2016-10-30 09:46:26 +00:00
msgid ""
"The only exceptions are magic methods and attributes (those that have "
"leading and trailing double underscores). Mock doesn't create these but "
"instead raises an :exc:`AttributeError`. This is because the interpreter "
"will often implicitly request these methods, and gets *very* confused to get "
"a new Mock object when it expects a magic method. If you need magic method "
"support see :ref:`magic methods <magic-methods>`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1029
2016-10-30 09:46:26 +00:00
msgid "The patchers"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1031
2016-10-30 09:46:26 +00:00
msgid ""
"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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1038
2016-10-30 09:46:26 +00:00
msgid "patch"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1042
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch` is straightforward to use. The key is to do the patching in "
"the right namespace. See the section `where to patch`_."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1047
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1052
2016-10-30 09:46:26 +00:00
msgid ""
"If *new* is omitted, then the target is replaced with a :class:`MagicMock`. "
"If :func:`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 :func:"
"`patch` is used as a context manager the created mock is returned by the "
"context manager."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1058
2016-10-30 09:46:26 +00:00
msgid ""
"*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 :func:`patch` from. The target is imported when the decorated "
"function is executed, not at decoration time."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1064
2016-10-30 09:46:26 +00:00
msgid ""
"The *spec* and *spec_set* keyword arguments are passed to the :class:"
"`MagicMock` if patch is creating one for you."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1067
2016-10-30 09:46:26 +00:00
msgid ""
"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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1070
2016-10-30 09:46:26 +00:00
msgid ""
"*new_callable* allows you to specify a different class, or callable object, "
"that will be called to create the *new* object. By default :class:"
"`MagicMock` is used."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1074
2016-10-30 09:46:26 +00:00
msgid ""
"A more powerful form of *spec* is *autospec*. If you set ``autospec=True`` "
"then the mock will 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 :exc:`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`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1084
2016-10-30 09:46:26 +00:00
msgid ""
"Instead of ``autospec=True`` you can pass ``autospec=some_object`` to use an "
"arbitrary object as the spec instead of the one being replaced."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1087
2016-10-30 09:46:26 +00:00
msgid ""
"By default :func:`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 default because "
"it can be dangerous. With it switched on you can write passing tests against "
"APIs that don't actually exist!"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1097
2016-10-30 09:46:26 +00:00
msgid ""
"If you are patching builtins in a module then you don't need to pass "
"``create=True``, it will be added by default."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1101
2016-10-30 09:46:26 +00:00
msgid ""
"Patch can be used as a :class:`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. :func:`patch` finds "
"tests by looking for method names that start with ``patch.TEST_PREFIX``. By "
"default this is ``'test'``, which matches the way :mod:`unittest` finds "
"tests. You can specify an alternative prefix by setting ``patch."
"TEST_PREFIX``."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1108
2016-10-30 09:46:26 +00:00
msgid ""
"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 :func:`patch` is creating a mock object for you."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1113
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch` takes arbitrary keyword arguments. These will be passed to "
"the :class:`Mock` (or *new_callable*) on construction."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1116
2016-10-30 09:46:26 +00:00
msgid ""
"``patch.dict(...)``, ``patch.multiple(...)`` and ``patch.object(...)`` are "
"available for alternate use-cases."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1119
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch` as function decorator, creating the mock for you and passing "
"it into the decorated function:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1129
2016-10-30 09:46:26 +00:00
msgid ""
"Patching a class replaces the class with a :class:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1133
2016-10-30 09:46:26 +00:00
msgid ""
"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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1137
2016-10-30 09:46:26 +00:00
msgid ""
"To configure return values on methods of *instances* on the patched class "
"you must do this on the :attr:`return_value`. For example:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1151
2016-10-30 09:46:26 +00:00
msgid ""
"If you use *spec* or *spec_set* and :func:`patch` is replacing a *class*, "
"then the return value of the created mock will have the same spec."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1161
2016-10-30 09:46:26 +00:00
msgid ""
"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:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1174
2016-10-30 09:46:26 +00:00
msgid ""
"Another use case might be to replace an object with an :class:`io.StringIO` "
"instance:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1187
2016-10-30 09:46:26 +00:00
msgid ""
"When :func:`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:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1199
2016-10-30 09:46:26 +00:00
msgid ""
"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 :"
"func:`patch` call using ``**``:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1217
2016-10-30 09:46:26 +00:00
msgid "patch.object"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1221
2016-10-30 09:46:26 +00:00
msgid ""
"patch the named member (*attribute*) on an object (*target*) with a mock "
"object."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1224
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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 :func:`patch`. Like :func:"
"`patch`, :func:`patch.object` takes arbitrary keyword arguments for "
"configuring the mock object it creates."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1230
2016-10-30 09:46:26 +00:00
msgid ""
"When used as a class decorator :func:`patch.object` honours ``patch."
"TEST_PREFIX`` for choosing which methods to wrap."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1233
2016-10-30 09:46:26 +00:00
msgid ""
"You can either call :func:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1237
2016-10-30 09:46:26 +00:00
msgid ""
"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:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1248
2016-10-30 09:46:26 +00:00
msgid ""
"*spec*, *create* and the other arguments to :func:`patch.object` have the "
"same meaning as they do for :func:`patch`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1253
2016-10-30 09:46:26 +00:00
msgid "patch.dict"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1257
2016-10-30 09:46:26 +00:00
msgid ""
"Patch a dictionary, or dictionary like object, and restore the dictionary to "
"its original state after the test."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1260
2016-10-30 09:46:26 +00:00
msgid ""
"*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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1264
2016-10-30 09:46:26 +00:00
msgid ""
"*in_dict* can also be a string specifying the name of the dictionary, which "
"will then be fetched by importing it."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1267
2016-10-30 09:46:26 +00:00
msgid ""
"*values* can be a dictionary of values to set in the dictionary. *values* "
"can also be an iterable of ``(key, value)`` pairs."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1270
2016-10-30 09:46:26 +00:00
msgid ""
"If *clear* is true then the dictionary will be cleared before the new values "
"are set."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1273
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch.dict` can also be called with arbitrary keyword arguments to "
"set values in the dictionary."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1276
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch.dict` can be used as a context manager, decorator or class "
"decorator. When used as a class decorator :func:`patch.dict` honours ``patch."
"TEST_PREFIX`` for choosing which methods to wrap."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1280
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1297
2016-10-30 09:46:26 +00:00
msgid ""
"Keywords can be used in the :func:`patch.dict` call to set values in the "
"dictionary:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1307
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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 :meth:`__getitem__`, :meth:`__setitem__`, :meth:"
"`__delitem__` and either :meth:`__iter__` or :meth:`__contains__`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1336
2016-10-30 09:46:26 +00:00
msgid "patch.multiple"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1340
2016-10-30 09:46:26 +00:00
msgid ""
"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::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1347
2016-10-30 09:46:26 +00:00
msgid ""
"Use :data:`DEFAULT` as the value if you want :func:`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 :func:"
"`patch.multiple` is used as a context manager."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1352
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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 :func:`patch`. These arguments "
"will be applied to *all* patches done by :func:`patch.multiple`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1357
2016-10-30 09:46:26 +00:00
msgid ""
"When used as a class decorator :func:`patch.multiple` honours ``patch."
"TEST_PREFIX`` for choosing which methods to wrap."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1360
2016-10-30 09:46:26 +00:00
msgid ""
"If you want :func:`patch.multiple` to create mocks for you, then you can "
"use :data:`DEFAULT` as the value. If you use :func:`patch.multiple` as a "
"decorator then the created mocks are passed into the decorated function by "
"keyword."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1374
2016-10-30 09:46:26 +00:00
msgid ""
":func:`patch.multiple` can be nested with other ``patch`` decorators, but "
"put arguments passed by keyword *after* any of the standard arguments "
"created by :func:`patch`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1386
2016-10-30 09:46:26 +00:00
msgid ""
"If :func:`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:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1400
2016-10-30 09:46:26 +00:00
msgid "patch methods: start and stop"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1402
2016-10-30 09:46:26 +00:00
msgid ""
"All the patchers have :meth:`start` and :meth:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1406
2016-10-30 09:46:26 +00:00
msgid ""
"To use them call :func:`patch`, :func:`patch.object` or :func:`patch.dict` "
"as normal and keep a reference to the returned ``patcher`` object. You can "
"then call :meth:`start` to put the patch in place and :meth:`stop` to undo "
"it."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1410
2016-10-30 09:46:26 +00:00
msgid ""
"If you are using :func:`patch` to create a mock for you then it will be "
"returned by the call to ``patcher.start``."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1424
2016-10-30 09:46:26 +00:00
msgid ""
"A typical use case for this might be for doing multiple patches in the "
"``setUp`` method of a :class:`TestCase`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1446
2016-10-30 09:46:26 +00:00
msgid ""
"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. :meth:"
"`unittest.TestCase.addCleanup` makes this easier:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1461
2016-10-30 09:46:26 +00:00
msgid ""
"As an added bonus you no longer need to keep a reference to the ``patcher`` "
"object."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1464
2016-10-30 09:46:26 +00:00
msgid ""
"It is also possible to stop all patches which have been started by using :"
"func:`patch.stopall`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1469
2016-10-30 09:46:26 +00:00
msgid "Stop all active patches. Only stops patches started with ``start``."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1475
2016-10-30 09:46:26 +00:00
msgid "patch builtins"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1476
2016-10-30 09:46:26 +00:00
msgid ""
"You can patch any builtins within a module. The following example patches "
"builtin :func:`ord`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1489
2016-10-30 09:46:26 +00:00
msgid "TEST_PREFIX"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1491
2016-10-30 09:46:26 +00:00
msgid ""
"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 :class:`unittest.TestLoader` finds test methods by default."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1496
2016-10-30 09:46:26 +00:00
msgid ""
"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``:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1519
2016-10-30 09:46:26 +00:00
msgid "Nesting Patch Decorators"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1521
2016-10-30 09:46:26 +00:00
msgid ""
"If you want to perform multiple patches then you can simply stack up the "
"decorators."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1524
2016-10-30 09:46:26 +00:00
msgid "You can stack up multiple patch decorators using this pattern:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1540
2016-10-30 09:46:26 +00:00
msgid ""
"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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1548
2016-10-30 09:46:26 +00:00
msgid "Where to patch"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1550
2016-10-30 09:46:26 +00:00
msgid ""
":func:`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1555
2016-10-30 09:46:26 +00:00
msgid ""
"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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1559
2016-10-30 09:46:26 +00:00
msgid ""
"Imagine we have a project that we want to test with the following structure::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1568
2016-10-30 09:46:26 +00:00
msgid ""
"Now we want to test ``some_function`` but we want to mock out ``SomeClass`` "
"using :func:`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 :func:"
"`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."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1575
2016-10-30 09:46:26 +00:00
msgid ""
"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::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1581
2016-10-30 09:46:26 +00:00
msgid ""
"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 in the module and so we have to patch "
"``a.SomeClass`` instead::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1590
2016-10-30 09:46:26 +00:00
msgid "Patching Descriptors and Proxy Objects"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1592
2016-10-30 09:46:26 +00:00
msgid ""
"Both patch_ and patch.object_ correctly patch and restore descriptors: class "
"methods, static methods and properties. You should patch these on the "
"*class* rather than an instance. They also work with *some* objects that "
"proxy attribute access, like the `django settings object <http://www."
"voidspace.org.uk/python/weblog/arch_d7_2010_12_04.shtml#e1198>`_."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1600
2016-10-30 09:46:26 +00:00
msgid "MagicMock and magic method support"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1605
2016-10-30 09:46:26 +00:00
msgid "Mocking Magic Methods"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1607
2016-10-30 09:46:26 +00:00
msgid ""
":class:`Mock` supports mocking the Python protocol methods, also known as "
"\"magic methods\". This allows mock objects to replace containers or other "
"objects that implement Python protocols."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1611
2016-10-30 09:46:26 +00:00
msgid ""
"Because magic methods are looked up differently from normal methods [#]_, "
"this support has been specially implemented. This means that only specific "
"magic methods are supported. The supported list includes *almost* all of "
"them. If there are any missing that you need please let us know."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1616
2016-10-30 09:46:26 +00:00
msgid ""
"You mock magic methods by setting the method you are interested in to a "
"function or a mock instance. If you are using a function then it *must* take "
"``self`` as the first argument [#]_."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1639
2016-10-30 09:46:26 +00:00
msgid ""
"One use case for this is for mocking objects used as context managers in a :"
"keyword:`with` statement:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1651
2016-10-30 09:46:26 +00:00
msgid ""
"Calls to magic methods do not appear in :attr:`~Mock.method_calls`, but they "
"are recorded in :attr:`~Mock.mock_calls`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1656
2016-10-30 09:46:26 +00:00
msgid ""
"If you use the *spec* keyword argument to create a mock then attempting to "
"set a magic method that isn't in the spec will raise an :exc:"
"`AttributeError`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1659
2016-10-30 09:46:26 +00:00
msgid "The full list of supported magic methods is:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1661
2016-10-30 09:46:26 +00:00
msgid "``__hash__``, ``__sizeof__``, ``__repr__`` and ``__str__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1662
2016-10-30 09:46:26 +00:00
msgid "``__dir__``, ``__format__`` and ``__subclasses__``"
msgstr "``__dir__``, ``__format__`` et ``__subclasses__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1663
2016-10-30 09:46:26 +00:00
msgid "``__floor__``, ``__trunc__`` and ``__ceil__``"
msgstr "``__floor__``, ``__trunc__`` et ``__ceil__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1664
2016-10-30 09:46:26 +00:00
msgid ""
"Comparisons: ``__lt__``, ``__gt__``, ``__le__``, ``__ge__``, ``__eq__`` and "
"``__ne__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1666
2016-10-30 09:46:26 +00:00
msgid ""
"Container methods: ``__getitem__``, ``__setitem__``, ``__delitem__``, "
"``__contains__``, ``__len__``, ``__iter__``, ``__reversed__`` and "
"``__missing__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1669
2016-10-30 09:46:26 +00:00
msgid "Context manager: ``__enter__`` and ``__exit__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1670
2016-10-30 09:46:26 +00:00
msgid "Unary numeric methods: ``__neg__``, ``__pos__`` and ``__invert__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1671
2016-10-30 09:46:26 +00:00
msgid ""
"The numeric methods (including right hand and in-place variants): "
"``__add__``, ``__sub__``, ``__mul__``, ``__matmul__``, ``__div__``, "
"``__truediv__``, ``__floordiv__``, ``__mod__``, ``__divmod__``, "
"``__lshift__``, ``__rshift__``, ``__and__``, ``__xor__``, ``__or__``, and "
"``__pow__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1675
2016-10-30 09:46:26 +00:00
msgid ""
"Numeric conversion methods: ``__complex__``, ``__int__``, ``__float__`` and "
"``__index__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1677
2016-10-30 09:46:26 +00:00
msgid "Descriptor methods: ``__get__``, ``__set__`` and ``__delete__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1678
2016-10-30 09:46:26 +00:00
msgid ""
"Pickling: ``__reduce__``, ``__reduce_ex__``, ``__getinitargs__``, "
"``__getnewargs__``, ``__getstate__`` and ``__setstate__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1682
2016-10-30 09:46:26 +00:00
msgid ""
"The following methods exist but are *not* supported as they are either in "
"use by mock, can't be set dynamically, or can cause problems:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1685
2016-10-30 09:46:26 +00:00
msgid "``__getattr__``, ``__setattr__``, ``__init__`` and ``__new__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1686
2016-10-30 09:46:26 +00:00
msgid ""
"``__prepare__``, ``__instancecheck__``, ``__subclasscheck__``, ``__del__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1691
2016-10-30 09:46:26 +00:00
msgid "Magic Mock"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1693
2016-10-30 09:46:26 +00:00
msgid ""
"There are two ``MagicMock`` variants: :class:`MagicMock` and :class:"
"`NonCallableMagicMock`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1698
2016-10-30 09:46:26 +00:00
msgid ""
"``MagicMock`` is a subclass of :class:`Mock` with default implementations of "
"most of the magic methods. You can use ``MagicMock`` without having to "
"configure the magic methods yourself."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1702
2016-10-30 09:46:26 +00:00
msgid "The constructor parameters have the same meaning as for :class:`Mock`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1704
2016-10-30 09:46:26 +00:00
msgid ""
"If you use the *spec* or *spec_set* arguments then *only* magic methods that "
"exist in the spec will be created."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1710
2016-10-30 09:46:26 +00:00
msgid "A non-callable version of :class:`MagicMock`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1712
2016-10-30 09:46:26 +00:00
msgid ""
"The constructor parameters have the same meaning as for :class:`MagicMock`, "
"with the exception of *return_value* and *side_effect* which have no meaning "
"on a non-callable mock."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1716
2016-10-30 09:46:26 +00:00
msgid ""
"The magic methods are setup with :class:`MagicMock` objects, so you can "
"configure them and use them in the usual way:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1726
2016-10-30 09:46:26 +00:00
msgid ""
"By default many of the protocol methods are required to return objects of a "
"specific type. These methods are preconfigured with a default return value, "
"so that they can be used without you having to do anything if you aren't "
"interested in the return value. You can still *set* the return value "
"manually if you want to change the default."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1732
2016-10-30 09:46:26 +00:00
msgid "Methods and their defaults:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1734
2016-10-30 09:46:26 +00:00
msgid "``__lt__``: NotImplemented"
msgstr "``__lt__``: NotImplemented"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1735
2016-10-30 09:46:26 +00:00
msgid "``__gt__``: NotImplemented"
msgstr "``__gt__``: NotImplemented"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1736
2016-10-30 09:46:26 +00:00
msgid "``__le__``: NotImplemented"
msgstr "``__le__``: NotImplemented"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1737
2016-10-30 09:46:26 +00:00
msgid "``__ge__``: NotImplemented"
msgstr "``__ge__``: NotImplemented"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1738
2016-10-30 09:46:26 +00:00
msgid "``__int__``: 1"
msgstr "``__int__``: 1"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1739
2016-10-30 09:46:26 +00:00
msgid "``__contains__``: False"
msgstr "``__contains__``: False"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1740
2016-10-30 09:46:26 +00:00
msgid "``__len__``: 0"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1741
2016-10-30 09:46:26 +00:00
msgid "``__iter__``: iter([])"
msgstr "``__iter__``: iter([])"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1742
2016-10-30 09:46:26 +00:00
msgid "``__exit__``: False"
msgstr "``__exit__``: False"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1743
2016-10-30 09:46:26 +00:00
msgid "``__complex__``: 1j"
msgstr "``__complex__``: 1j"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1744
2016-10-30 09:46:26 +00:00
msgid "``__float__``: 1.0"
msgstr "``__float__``: 1.0"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1745
2016-10-30 09:46:26 +00:00
msgid "``__bool__``: True"
msgstr "``__bool__``: True"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1746
2016-10-30 09:46:26 +00:00
msgid "``__index__``: 1"
msgstr "``__index__``: 1"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1747
2016-10-30 09:46:26 +00:00
msgid "``__hash__``: default hash for the mock"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1748
2016-10-30 09:46:26 +00:00
msgid "``__str__``: default str for the mock"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1749
2016-10-30 09:46:26 +00:00
msgid "``__sizeof__``: default sizeof for the mock"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1751
2016-10-30 09:46:26 +00:00
msgid "For example:"
msgstr "Par exemple : ::"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1763
2016-10-30 09:46:26 +00:00
msgid ""
"The two equality methods, :meth:`__eq__` and :meth:`__ne__`, are special. "
"They do the default equality comparison on identity, using the :attr:`~Mock."
"side_effect` attribute, unless you change their return value to return "
"something else::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1777
2016-10-30 09:46:26 +00:00
msgid ""
"The return value of :meth:`MagicMock.__iter__` can be any iterable object "
"and isn't required to be an iterator:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1787
2016-10-30 09:46:26 +00:00
msgid ""
"If the return value *is* an iterator, then iterating over it once will "
"consume it and subsequent iterations will result in an empty list:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1796
2016-10-30 09:46:26 +00:00
msgid ""
"``MagicMock`` has all of the supported magic methods configured except for "
"some of the obscure and obsolete ones. You can still set these up if you "
"want."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1799
2016-10-30 09:46:26 +00:00
msgid ""
"Magic methods that are supported but not setup by default in ``MagicMock`` "
"are:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1801
2016-10-30 09:46:26 +00:00
msgid "``__subclasses__``"
msgstr "``__subclasses__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1802
2016-10-30 09:46:26 +00:00
msgid "``__dir__``"
msgstr "``__dir__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1803
2016-10-30 09:46:26 +00:00
msgid "``__format__``"
msgstr "``__format__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1804
2016-10-30 09:46:26 +00:00
msgid "``__get__``, ``__set__`` and ``__delete__``"
msgstr "``__get__``, ``__set__`` et ``__delete__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1805
2016-10-30 09:46:26 +00:00
msgid "``__reversed__`` and ``__missing__``"
msgstr "``__reversed__`` et ``__missing__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1806
2016-10-30 09:46:26 +00:00
msgid ""
"``__reduce__``, ``__reduce_ex__``, ``__getinitargs__``, ``__getnewargs__``, "
"``__getstate__`` and ``__setstate__``"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1808
2016-10-30 09:46:26 +00:00
msgid "``__getformat__`` and ``__setformat__``"
msgstr "``__getformat__`` et ``__setformat__``"
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1812
2016-10-30 09:46:26 +00:00
msgid ""
"Magic methods *should* be looked up on the class rather than the instance. "
"Different versions of Python are inconsistent about applying this rule. The "
"supported protocol methods should work with all supported versions of Python."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1816
2016-10-30 09:46:26 +00:00
msgid ""
"The function is basically hooked up to the class, but each ``Mock`` instance "
"is kept isolated from the others."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1821
2016-10-30 09:46:26 +00:00
msgid "Helpers"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1824
2016-10-30 09:46:26 +00:00
msgid "sentinel"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1828
2016-10-30 09:46:26 +00:00
msgid ""
"The ``sentinel`` object provides a convenient way of providing unique "
"objects for your tests."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1831
2016-10-30 09:46:26 +00:00
msgid ""
"Attributes are created on demand when you access them by name. Accessing the "
"same attribute will always return the same object. The objects returned have "
"a sensible repr so that test failure messages are readable."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1835
msgid ""
"The ``sentinel`` attributes don't preserve their identity when they are :mod:"
"`copied <copy>` or :mod:`pickled <pickle>`."
msgstr ""
#: ../Doc/library/unittest.mock.rst:1838
2016-10-30 09:46:26 +00:00
msgid ""
"Sometimes when testing you need to test that a specific object is passed as "
"an argument to another method, or returned. It can be common to create named "
"sentinel objects to test this. :data:`sentinel` provides a convenient way of "
"creating and testing the identity of objects like this."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1843
2016-10-30 09:46:26 +00:00
msgid ""
"In this example we monkey patch ``method`` to return ``sentinel."
"some_object``:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1855
2016-10-30 09:46:26 +00:00
msgid "DEFAULT"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1860
2016-10-30 09:46:26 +00:00
msgid ""
"The :data:`DEFAULT` object is a pre-created sentinel (actually ``sentinel."
"DEFAULT``). It can be used by :attr:`~Mock.side_effect` functions to "
"indicate that the normal return value should be used."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1866
2016-10-30 09:46:26 +00:00
msgid "call"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1870
2016-10-30 09:46:26 +00:00
msgid ""
":func:`call` is a helper object for making simpler assertions, for comparing "
"with :attr:`~Mock.call_args`, :attr:`~Mock.call_args_list`, :attr:`~Mock."
"mock_calls` and :attr:`~Mock.method_calls`. :func:`call` can also be used "
"with :meth:`~Mock.assert_has_calls`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1883
2016-10-30 09:46:26 +00:00
msgid ""
"For a call object that represents multiple calls, :meth:`call_list` returns "
"a list of all the intermediate calls as well as the final call."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1887
2016-10-30 09:46:26 +00:00
msgid ""
"``call_list`` is particularly useful for making assertions on \"chained calls"
"\". A chained call is multiple calls on a single line of code. This results "
"in multiple entries in :attr:`~Mock.mock_calls` on a mock. Manually "
"constructing the sequence of calls can be tedious."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1892
2016-10-30 09:46:26 +00:00
msgid ""
":meth:`~call.call_list` can construct the sequence of calls from the same "
"chained call:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1909
2016-10-30 09:46:26 +00:00
msgid ""
"A ``call`` object is either a tuple of (positional args, keyword args) or "
"(name, positional args, keyword args) depending on how it was constructed. "
"When you construct them yourself this isn't particularly interesting, but "
"the ``call`` objects that are in the :attr:`Mock.call_args`, :attr:`Mock."
"call_args_list` and :attr:`Mock.mock_calls` attributes can be introspected "
"to get at the individual arguments they contain."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1916
2016-10-30 09:46:26 +00:00
msgid ""
"The ``call`` objects in :attr:`Mock.call_args` and :attr:`Mock."
"call_args_list` are two-tuples of (positional args, keyword args) whereas "
"the ``call`` objects in :attr:`Mock.mock_calls`, along with ones you "
"construct yourself, are three-tuples of (name, positional args, keyword "
"args)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1921
2016-10-30 09:46:26 +00:00
msgid ""
"You can use their \"tupleness\" to pull out the individual arguments for "
"more complex introspection and assertions. The positional arguments are a "
"tuple (an empty tuple if there are no positional arguments) and the keyword "
"arguments are a dictionary:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1955
2016-10-30 09:46:26 +00:00
msgid "create_autospec"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1959
2016-10-30 09:46:26 +00:00
msgid ""
"Create a mock object using another object as a spec. Attributes on the mock "
"will use the corresponding attribute on the *spec* object as their spec."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1963
2016-10-30 09:46:26 +00:00
msgid ""
"Functions or methods being mocked will have their arguments checked to "
"ensure that they are called with the correct signature."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1966
2016-10-30 09:46:26 +00:00
msgid ""
"If *spec_set* is ``True`` then attempting to set attributes that don't exist "
"on the spec object will raise an :exc:`AttributeError`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1969
2016-10-30 09:46:26 +00:00
msgid ""
"If a class is used as a spec then the return value of the mock (the instance "
"of the class) will have the same spec. You can use a class as the spec for "
"an instance object by passing ``instance=True``. The returned mock will only "
"be callable if instances of the mock are callable."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1974
2016-10-30 09:46:26 +00:00
msgid ""
":func:`create_autospec` also takes arbitrary keyword arguments that are "
"passed to the constructor of the created mock."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1977
2016-10-30 09:46:26 +00:00
msgid ""
"See :ref:`auto-speccing` for examples of how to use auto-speccing with :func:"
"`create_autospec` and the *autospec* argument to :func:`patch`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1982
2016-10-30 09:46:26 +00:00
msgid "ANY"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1986
2016-10-30 09:46:26 +00:00
msgid ""
"Sometimes you may need to make assertions about *some* of the arguments in a "
"call to mock, but either not care about some of the arguments or want to "
"pull them individually out of :attr:`~Mock.call_args` and make more complex "
"assertions on them."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:1991
2016-10-30 09:46:26 +00:00
msgid ""
"To ignore certain arguments you can pass in objects that compare equal to "
"*everything*. Calls to :meth:`~Mock.assert_called_with` and :meth:`~Mock."
"assert_called_once_with` will then succeed no matter what was passed in."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2000
2016-10-30 09:46:26 +00:00
msgid ""
":data:`ANY` can also be used in comparisons with call lists like :attr:"
"`~Mock.mock_calls`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2013
2016-10-30 09:46:26 +00:00
msgid "FILTER_DIR"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2017
2016-10-30 09:46:26 +00:00
msgid ""
":data:`FILTER_DIR` is a module level variable that controls the way mock "
"objects respond to :func:`dir` (only for Python 2.6 or more recent). The "
"default is ``True``, which uses the filtering described below, to only show "
"useful members. If you dislike this filtering, or need to switch it off for "
"diagnostic purposes, then set ``mock.FILTER_DIR = False``."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2023
2016-10-30 09:46:26 +00:00
msgid ""
"With filtering on, ``dir(some_mock)`` shows only useful attributes and will "
"include any dynamically created attributes that wouldn't normally be shown. "
"If the mock was created with a *spec* (or *autospec* of course) then all the "
"attributes from the original are shown, even if they haven't been accessed "
"yet:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2044
2016-10-30 09:46:26 +00:00
msgid ""
"Many of the not-very-useful (private to :class:`Mock` rather than the thing "
"being mocked) underscore and double underscore prefixed attributes have been "
"filtered from the result of calling :func:`dir` on a :class:`Mock`. If you "
"dislike this behaviour you can switch it off by setting the module level "
"switch :data:`FILTER_DIR`:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2062
2016-10-30 09:46:26 +00:00
msgid ""
"Alternatively you can just use ``vars(my_mock)`` (instance members) and "
"``dir(type(my_mock))`` (type members) to bypass the filtering irrespective "
"of :data:`mock.FILTER_DIR`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2068
2016-10-30 09:46:26 +00:00
msgid "mock_open"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2072
2016-10-30 09:46:26 +00:00
msgid ""
"A helper function to create a mock to replace the use of :func:`open`. It "
"works for :func:`open` called directly or used as a context manager."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2075
2016-10-30 09:46:26 +00:00
msgid ""
"The *mock* argument is the mock object to configure. If ``None`` (the "
"default) then a :class:`MagicMock` will be created for you, with the API "
"limited to methods or attributes available on standard file handles."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2079
2016-10-30 09:46:26 +00:00
msgid ""
"*read_data* is a string for the :meth:`~io.IOBase.read`, :meth:`~io.IOBase."
"readline`, and :meth:`~io.IOBase.readlines` methods of the file handle to "
"return. Calls to those methods will take data from *read_data* until it is "
"depleted. The mock of these methods is pretty simplistic: every time the "
"*mock* is called, the *read_data* is rewound to the start. If you need more "
"control over the data that you are feeding to the tested code you will need "
"to customize this mock for yourself. When that is insufficient, one of the "
"in-memory filesystem packages on `PyPI <https://pypi.python.org/pypi>`_ can "
"offer a realistic filesystem for testing."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2089
2016-10-30 09:46:26 +00:00
msgid ""
"Added :meth:`~io.IOBase.readline` and :meth:`~io.IOBase.readlines` support. "
"The mock of :meth:`~io.IOBase.read` changed to consume *read_data* rather "
"than returning it on each call."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2094
2016-10-30 09:46:26 +00:00
msgid "*read_data* is now reset on each call to the *mock*."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2097
2016-10-30 09:46:26 +00:00
msgid ""
"Using :func:`open` as a context manager is a great way to ensure your file "
"handles are closed properly and is becoming common::"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2103
2016-10-30 09:46:26 +00:00
msgid ""
"The issue is that even if you mock out the call to :func:`open` it is the "
"*returned object* that is used as a context manager (and has :meth:"
"`__enter__` and :meth:`__exit__` called)."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2107
2016-10-30 09:46:26 +00:00
msgid ""
"Mocking context managers with a :class:`MagicMock` is common enough and "
"fiddly enough that a helper function is useful."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2124
2016-10-30 09:46:26 +00:00
msgid "And for reading files:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2137
2016-10-30 09:46:26 +00:00
msgid "Autospeccing"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2139
2016-10-30 09:46:26 +00:00
msgid ""
"Autospeccing is based on the existing :attr:`spec` feature of mock. It "
"limits the api of mocks to the api of an original object (the spec), but it "
"is recursive (implemented lazily) so that attributes of mocks only have the "
"same api as the attributes of the spec. In addition mocked functions / "
"methods have the same call signature as the original so they raise a :exc:"
"`TypeError` if they are called incorrectly."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2146
2016-10-30 09:46:26 +00:00
msgid "Before I explain how auto-speccing works, here's why it is needed."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2148
2016-10-30 09:46:26 +00:00
msgid ""
":class:`Mock` is a very powerful and flexible object, but it suffers from "
"two flaws when used to mock out objects from a system under test. One of "
"these flaws is specific to the :class:`Mock` api and the other is a more "
"general problem with using mock objects."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2153
2016-10-30 09:46:26 +00:00
msgid ""
"First the problem specific to :class:`Mock`. :class:`Mock` has two assert "
"methods that are extremely handy: :meth:`~Mock.assert_called_with` and :meth:"
"`~Mock.assert_called_once_with`."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2166
2016-10-30 09:46:26 +00:00
msgid ""
"Because mocks auto-create attributes on demand, and allow you to call them "
"with arbitrary arguments, if you misspell one of these assert methods then "
"your assertion is gone:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2176
2016-10-30 09:46:26 +00:00
msgid "Your tests can pass silently and incorrectly because of the typo."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2178
2016-10-30 09:46:26 +00:00
msgid ""
"The second issue is more general to mocking. If you refactor some of your "
"code, rename members and so on, any tests for code that is still using the "
"*old api* but uses mocks instead of the real objects will still pass. This "
"means your tests can all pass even though your code is broken."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2183
2016-10-30 09:46:26 +00:00
msgid ""
"Note that this is another reason why you need integration tests as well as "
"unit tests. Testing everything in isolation is all fine and dandy, but if "
"you don't test how your units are \"wired together\" there is still lots of "
"room for bugs that tests might have caught."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2188
2016-10-30 09:46:26 +00:00
msgid ""
":mod:`mock` already provides a feature to help with this, called speccing. "
"If you use a class or instance as the :attr:`spec` for a mock then you can "
"only access attributes on the mock that exist on the real class:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2199
2016-10-30 09:46:26 +00:00
msgid ""
"The spec only applies to the mock itself, so we still have the same issue "
"with any methods on the mock:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2208
2016-10-30 09:46:26 +00:00
msgid ""
"Auto-speccing solves this problem. You can either pass ``autospec=True`` to :"
"func:`patch` / :func:`patch.object` or use the :func:`create_autospec` "
"function to create a mock with a spec. If you use the ``autospec=True`` "
"argument to :func:`patch` then the object that is being replaced will be "
"used as the spec object. Because the speccing is done \"lazily\" (the spec "
"is created as attributes on the mock are accessed) you can use it with very "
"complex or deeply nested objects (like modules that import modules that "
"import modules) without a big performance hit."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2217
2016-10-30 09:46:26 +00:00
msgid "Here's an example of it in use:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2227
2016-10-30 09:46:26 +00:00
msgid ""
"You can see that :class:`request.Request` has a spec. :class:`request."
"Request` takes two arguments in the constructor (one of which is *self*). "
"Here's what happens if we try to call it incorrectly:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2236
2016-10-30 09:46:26 +00:00
msgid ""
"The spec also applies to instantiated classes (i.e. the return value of "
"specced mocks):"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2243
2016-10-30 09:46:26 +00:00
msgid ""
":class:`Request` objects are not callable, so the return value of "
"instantiating our mocked out :class:`request.Request` is a non-callable "
"mock. With the spec in place any typos in our asserts will raise the correct "
"error:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2255
2016-10-30 09:46:26 +00:00
msgid ""
"In many cases you will just be able to add ``autospec=True`` to your "
"existing :func:`patch` calls and then be protected against bugs due to typos "
"and api changes."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2259
2016-10-30 09:46:26 +00:00
msgid ""
"As well as using *autospec* through :func:`patch` there is a :func:"
"`create_autospec` for creating autospecced mocks directly:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2267
2016-10-30 09:46:26 +00:00
msgid ""
"This isn't without caveats and limitations however, which is why it is not "
"the default behaviour. In order to know what attributes are available on the "
"spec object, autospec has to introspect (access attributes) the spec. As you "
"traverse attributes on the mock a corresponding traversal of the original "
"object is happening under the hood. If any of your specced objects have "
"properties or descriptors that can trigger code execution then you may not "
"be able to use autospec. On the other hand it is much better to design your "
"objects so that introspection is safe [#]_."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2276
2016-10-30 09:46:26 +00:00
msgid ""
"A more serious problem is that it is common for instance attributes to be "
"created in the :meth:`__init__` method and not to exist on the class at all. "
"*autospec* can't know about any dynamically created attributes and restricts "
"the api to visible attributes."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2293
2016-10-30 09:46:26 +00:00
msgid ""
"There are a few different ways of resolving this problem. The easiest, but "
"not necessarily the least annoying, way is to simply set the required "
"attributes on the mock after creation. Just because *autospec* doesn't allow "
"you to fetch attributes that don't exist on the spec it doesn't prevent you "
"setting them:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2304
2016-10-30 09:46:26 +00:00
msgid ""
"There is a more aggressive version of both *spec* and *autospec* that *does* "
"prevent you setting non-existent attributes. This is useful if you want to "
"ensure your code only *sets* valid attributes too, but obviously it prevents "
"this particular scenario:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2317
2016-10-30 09:46:26 +00:00
msgid ""
"Probably the best way of solving the problem is to add class attributes as "
"default values for instance members initialised in :meth:`__init__`. Note "
"that if you are only setting default attributes in :meth:`__init__` then "
"providing them via class attributes (shared between instances of course) is "
"faster too. e.g."
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2327
2016-10-30 09:46:26 +00:00
msgid ""
"This brings up another issue. It is relatively common to provide a default "
"value of ``None`` for members that will later be an object of a different "
"type. ``None`` would be useless as a spec because it wouldn't let you access "
"*any* attributes or methods on it. As ``None`` is *never* going to be useful "
"as a spec, and probably indicates a member that will normally of some other "
"type, autospec doesn't use a spec for members that are set to ``None``. "
"These will just be ordinary mocks (well - MagicMocks):"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2342
2016-10-30 09:46:26 +00:00
msgid ""
"If modifying your production classes to add defaults isn't to your liking "
"then there are more options. One of these is simply to use an instance as "
"the spec rather than the class. The other is to create a subclass of the "
"production class and add the defaults to the subclass without affecting the "
"production class. Both of these require you to use an alternative object as "
"the spec. Thankfully :func:`patch` supports this - you can simply pass the "
"alternative object as the *autospec* argument:"
msgstr ""
2017-04-02 20:14:06 +00:00
#: ../Doc/library/unittest.mock.rst:2363
2016-10-30 09:46:26 +00:00
msgid ""
"This only applies to classes or already instantiated objects. Calling a "
"mocked class to create a mock instance *does not* create a real instance. It "
"is only attribute lookups - along with calls to :func:`dir` - that are done."
msgstr ""