[Python-checkins] cpython (merge 3.3 -> default): merge with 3.3
georg.brandl
python-checkins at python.org
Sun Feb 3 13:59:31 CET 2013
http://hg.python.org/cpython/rev/6c4857832510
changeset: 81966:6c4857832510
parent: 81964:3f733a63c8c8
parent: 81965:9040b3714207
user: Georg Brandl <georg at python.org>
date: Sun Feb 03 14:00:38 2013 +0100
summary:
merge with 3.3
files:
Doc/library/unittest.mock-examples.rst | 28 +++++++-------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Doc/library/unittest.mock-examples.rst b/Doc/library/unittest.mock-examples.rst
--- a/Doc/library/unittest.mock-examples.rst
+++ b/Doc/library/unittest.mock-examples.rst
@@ -432,14 +432,14 @@
.. _further-examples:
Further Examples
-================
+----------------
Here are some more examples for some slightly more advanced scenarios.
Mocking chained calls
----------------------
+~~~~~~~~~~~~~~~~~~~~~
Mocking chained calls is actually straightforward with mock once you
understand the :attr:`~Mock.return_value` attribute. When a mock is called for
@@ -510,7 +510,7 @@
Partial mocking
----------------
+~~~~~~~~~~~~~~~
In some tests I wanted to mock out a call to `datetime.date.today()
<http://docs.python.org/library/datetime.html#datetime.date.today>`_ to return
@@ -554,7 +554,7 @@
Mocking a Generator Method
---------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~
A Python generator is a function or method that uses the `yield statement
<http://docs.python.org/reference/simple_stmts.html#the-yield-statement>`_ to
@@ -596,7 +596,7 @@
Applying the same patch to every test method
---------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want several patches in place for multiple test methods the obvious way
is to apply the patch decorators to every method. This can feel like unnecessary
@@ -656,7 +656,7 @@
Mocking Unbound Methods
------------------------
+~~~~~~~~~~~~~~~~~~~~~~~
Whilst writing tests today I needed to patch an *unbound method* (patching the
method on the class rather than on the instance). I needed self to be passed
@@ -695,7 +695,7 @@
Checking multiple calls with mock
----------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mock has a nice API for making assertions about how your mock objects are used.
@@ -737,7 +737,7 @@
Coping with mutable arguments
------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another situation is rare, but can bite you, is when your mock is called with
mutable arguments. `call_args` and `call_args_list` store *references* to the
@@ -853,7 +853,7 @@
Nesting Patches
----------------
+~~~~~~~~~~~~~~~
Using patch as a context manager is nice, but if you do multiple patches you
can end up with nested with statements indenting further and further to the
@@ -901,7 +901,7 @@
Mocking a dictionary with MagicMock
------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may want to mock a dictionary, or other container object, recording all
access to it whilst having it still behave like a dictionary.
@@ -976,7 +976,7 @@
Mock subclasses and their attributes
-------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are various reasons why you might want to subclass `Mock`. One reason
might be to add helper methods. Here's a silly example:
@@ -1039,7 +1039,7 @@
Mocking imports with patch.dict
--------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One situation where mocking can be hard is where you have a local import inside
a function. These are harder to mock because they aren't using an object from
@@ -1102,7 +1102,7 @@
Tracking order of calls and less verbose call assertions
---------------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :class:`Mock` class allows you to track the *order* of method calls on
your mock objects through the :attr:`~Mock.method_calls` attribute. This
@@ -1182,7 +1182,7 @@
More complex argument matching
-------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using the same basic concept as :data:`ANY` we can implement matchers to do more
complex assertions on objects used as arguments to mocks.
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list