diff options
| -rw-r--r-- | 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 index 36926cd514..cbdba1d3a6 100644 --- a/Doc/library/unittest.mock-examples.rst +++ b/Doc/library/unittest.mock-examples.rst @@ -432,14 +432,14 @@ decorator indvidually to every method whose name starts with "test". .. _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 @@ this list of calls for us: 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 @@ is discussed in `this blog entry 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 @@ To configure the values returned from the iteration (implicit in the call to 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 @@ exception is raised in the setUp then tearDown is not called. 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 @@ with a Mock instance instead, and isn't called with `self`. Checking multiple calls with mock ---------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mock has a nice API for making assertions about how your mock objects are used. @@ -737,7 +737,7 @@ looks remarkably similar to the repr of the `call_args_list`: 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 @@ children of a `CopyingMock` will also have the type `CopyingMock`. 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 @@ for us: 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 methods and attributes: 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 @@ onto the mock constructor: 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 @@ With slightly more work you can also mock package imports: 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 @@ order. In this case you can pass `any_order=True` to `assert_has_calls`: 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. |