Skip to content

Commit

Permalink
pythongh-118912: Remove description of issue fixed in 3.5 from autosp…
Browse files Browse the repository at this point in the history
…eccing guide (pythonGH-119232)

* Remove description of issue fixed in 3.5 from autospeccing guide

* Make autospeccing note text more succint and lint whitespace

* Add linting changes (missed in last commit)

---------

(cherry picked from commit 7e57640)

Co-authored-by: Shauna <shaunagm@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
  • Loading branch information
2 people authored and miss-islington committed May 20, 2024
1 parent d8fbe5b commit 96e5553
Showing 1 changed file with 8 additions and 32 deletions.
40 changes: 8 additions & 32 deletions Doc/library/unittest.mock.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2584,40 +2584,16 @@ called incorrectly.

Before I explain how auto-speccing works, here's why it is needed.

: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.

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`.

>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
>>> mock.assert_called_once_with(1, 2, 3)
>>> mock(1, 2, 3)
>>> mock.assert_called_once_with(1, 2, 3)
Traceback (most recent call last):
...
AssertionError: Expected 'mock' to be called once. Called 2 times.

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:

.. code-block:: pycon
>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
>>> mock.assret_called_once_with(4, 5, 6) # Intentional typo!
:class:`Mock` is a very powerful and flexible object, but it suffers from a flaw which
is 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.

Your tests can pass silently and incorrectly because of the typo.
.. versionchanged:: 3.5

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.
Before 3.5, tests with a typo in the word assert would silently pass when they should
raise an error. You can still achieve this behavior by passing ``unsafe=True`` to Mock.

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
Expand Down

0 comments on commit 96e5553

Please sign in to comment.