8000 [3.12] gh-118912: Remove description of issue fixed in 3.5 from autos… · python/cpython@d8981ab · GitHub
[go: up one dir, main page]

Skip to content

Commit d8981ab

Browse files
miss-islingtonshaunagmwillingc
authored
[3.12] gh-118912: Remove description of issue fixed in 3.5 from autospeccing guide (GH-119232) (#119283)
gh-118912: Remove description of issue fixed in 3.5 from autospeccing guide (GH-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>
1 parent ec5743b commit d8981ab

File tree

1 file changed

+8
-32
lines changed

1 file changed

+8
-32
lines changed

Doc/library/unittest.mock.rst

Lines changed: 8 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -2535,40 +2535,16 @@ called incorrectly.
25352535

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

2538-
:class:`Mock` is a very powerful and flexible object, but it suffers from two flaws
2539-
when used to mock out objects from a system under test. One of these flaws is
2540-
specific to the :class:`Mock` api and the other is a more general problem with using
2541-
mock objects.
2542-
2543-
First the problem specific to :class:`Mock`. :class:`Mock` has two assert methods that are
2544-
extremely handy: :meth:`~Mock.assert_called_with` and
2545-
:meth:`~Mock.assert_called_once_with`.
2546-
2547-
>>> mock = Mock(name='Thing', return_value=None)
2548-
>>> mock(1, 2, 3)
2549-
>>> mock.assert_called_once_with(1, 2, 3)
2550-
>>> mock(1, 2, 3)
2551-
>>> mock.assert_called_once_with(1, 2, 3)
2552-
Traceback (most recent call last):
2553-
...
2554-
AssertionError: Expected 'mock' to be called once. Called 2 times.
2555-
2556-
Because mocks auto-create attributes on demand, and allow you to call them
2557-
with arbitrary arguments, if you misspell one of these assert methods then
2558-
your assertion is gone:
2559-
2560-
.. code-block:: pycon
2561-
2562-
>>> mock = Mock(name='Thing', return_value=None)
2563-
>>> mock(1, 2, 3)
2564-
>>> mock.assret_called_once_with(4, 5, 6) # Intentional typo!
2538+
:class:`Mock` is a very powerful and flexible object, but it suffers from a flaw which
2539+
is general to mocking. If you refactor some of your code, rename members and so on, any
2540+
tests for code that is still using the *old api* but uses mocks instead of the real
2541+
objects will still pass. This means your tests can all pass even though your code is
2542+
broken.
25652543

2566-
Your tests can pass silently and incorrectly because of the typo.
2544+
.. versionchanged:: 3.5
25672545

2568-
The second issue is more general to mocking. If you refactor some of your
2569-
code, rename members and so on, any tests for code that is still using the
2570-
*old api* but uses mocks instead of the real objects will still pass. This
2571-
means your tests can all pass even though your code is broken.
2546+
Before 3.5, tests with a typo in the word assert would silently pass when they should
2547+
raise an error. You can still achieve this behavior by passing ``unsafe=True`` to Mock.
25722548

25732549
Note that this is another reason why you need integration tests as well as
25742550
unit tests. Testing everything in isolation is all fine and dandy, but if you

0 commit comments

Comments
 (0)
0