Skip to content

Commit

Permalink
gh-101100: Fix sphinx warnings in unittest.mock-examples.rst (#108810)
Browse files Browse the repository at this point in the history
  • Loading branch information
sobolevn authored Sep 2, 2023
1 parent dd05c20 commit 5141b1e
Show file tree
Hide file tree
Showing 3 changed files with 8 additions and 8 deletions.
13 changes: 7 additions & 6 deletions Doc/library/unittest.mock-examples.rst
Original file line number Diff line number Diff line change
Expand Up @@ -579,14 +579,14 @@ Partial mocking
In some tests I wanted to mock out a call to :meth:`datetime.date.today`
to return a known date, but I didn't want to prevent the code under test from
creating new date objects. Unfortunately :class:`datetime.date` is written in C, and
so I couldn't just monkey-patch out the static :meth:`date.today` method.
so I couldn't just monkey-patch out the static :meth:`datetime.date.today` method.

I found a simple way of doing this that involved effectively wrapping the date
class with a mock, but passing through calls to the constructor to the real
class (and returning real instances).

The :func:`patch decorator <patch>` is used here to
mock out the ``date`` class in the module under test. The :attr:`side_effect`
mock out the ``date`` class in the module under test. The :attr:`~Mock.side_effect`
attribute on the mock date class is then set to a lambda function that returns
a real date. When the mock date class is called a real date will be
constructed and returned by ``side_effect``. ::
Expand Down Expand Up @@ -766,8 +766,8 @@ mock has a nice API for making assertions about how your mock objects are used.
>>> mock.foo_bar.assert_called_with('baz', spam='eggs')

If your mock is only being called once you can use the
:meth:`assert_called_once_with` method that also asserts that the
:attr:`call_count` is one.
:meth:`~Mock.assert_called_once_with` method that also asserts that the
:attr:`~Mock.call_count` is one.

>>> mock.foo_bar.assert_called_once_with('baz', spam='eggs')
>>> mock.foo_bar()
Expand Down Expand Up @@ -835,7 +835,7 @@ One possibility would be for mock to copy the arguments you pass in. This
could then cause problems if you do assertions that rely on object identity
for equality.

Here's one solution that uses the :attr:`side_effect`
Here's one solution that uses the :attr:`~Mock.side_effect`
functionality. If you provide a ``side_effect`` function for a mock then
``side_effect`` will be called with the same args as the mock. This gives us an
opportunity to copy the arguments and store them for later assertions. In this
Expand Down Expand Up @@ -971,7 +971,8 @@ We can do this with :class:`MagicMock`, which will behave like a dictionary,
and using :data:`~Mock.side_effect` to delegate dictionary access to a real
underlying dictionary that is under our control.

When the :meth:`__getitem__` and :meth:`__setitem__` methods of our ``MagicMock`` are called
When the :meth:`~object.__getitem__` and :meth:`~object.__setitem__` methods
of our ``MagicMock`` are called
(normal dictionary access) then ``side_effect`` is called with the key (and in
the case of ``__setitem__`` the value too). We can also control what is returned.

Expand Down
2 changes: 1 addition & 1 deletion Doc/library/uuid.rst
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@ which relays any information about the UUID's safety, using this enumeration:
- Meaning

* - .. attribute:: UUID.time_low
- The next 32 bits of the UUID.
- The first 32 bits of the UUID.

* - .. attribute:: UUID.time_mid
- The next 16 bits of the UUID.
Expand Down
1 change: 0 additions & 1 deletion Doc/tools/.nitignore
Original file line number Diff line number Diff line change
Expand Up @@ -131,7 +131,6 @@ Doc/library/tkinter.ttk.rst
Doc/library/traceback.rst
Doc/library/tty.rst
Doc/library/turtle.rst
Doc/library/unittest.mock-examples.rst
Doc/library/unittest.mock.rst
Doc/library/unittest.rst
Doc/library/urllib.parse.rst
Expand Down

0 comments on commit 5141b1e

Please sign in to comment.