Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 1 | .. _further-examples: |
| 2 | |
| 3 | ================== |
| 4 | Further Examples |
| 5 | ================== |
| 6 | |
| 7 | .. currentmodule:: mock |
| 8 | |
| 9 | .. testsetup:: |
| 10 | |
| 11 | from datetime import date |
| 12 | |
| 13 | BackendProvider = Mock() |
| 14 | sys.modules['mymodule'] = mymodule = Mock(name='mymodule') |
| 15 | |
| 16 | def grob(val): |
| 17 | "First frob and then clear val" |
| 18 | mymodule.frob(val) |
| 19 | val.clear() |
| 20 | |
| 21 | mymodule.frob = lambda val: val |
| 22 | mymodule.grob = grob |
| 23 | mymodule.date = date |
| 24 | |
| 25 | class TestCase(unittest2.TestCase): |
| 26 | def run(self): |
| 27 | result = unittest2.TestResult() |
| 28 | out = unittest2.TestCase.run(self, result) |
| 29 | assert result.wasSuccessful() |
| 30 | |
| 31 | from mock import inPy3k |
| 32 | |
| 33 | |
| 34 | |
| 35 | For comprehensive examples, see the unit tests included in the full source |
| 36 | distribution. |
| 37 | |
| 38 | Here are some more examples for some slightly more advanced scenarios than in |
| 39 | the :ref:`getting started <getting-started>` guide. |
| 40 | |
| 41 | |
| 42 | Mocking chained calls |
| 43 | ===================== |
| 44 | |
| 45 | Mocking chained calls is actually straightforward with mock once you |
| 46 | understand the :attr:`~Mock.return_value` attribute. When a mock is called for |
| 47 | the first time, or you fetch its `return_value` before it has been called, a |
| 48 | new `Mock` is created. |
| 49 | |
| 50 | This means that you can see how the object returned from a call to a mocked |
| 51 | object has been used by interrogating the `return_value` mock: |
| 52 | |
| 53 | .. doctest:: |
| 54 | |
| 55 | >>> mock = Mock() |
| 56 | >>> mock().foo(a=2, b=3) |
| 57 | <Mock name='mock().foo()' id='...'> |
| 58 | >>> mock.return_value.foo.assert_called_with(a=2, b=3) |
| 59 | |
| 60 | From here it is a simple step to configure and then make assertions about |
| 61 | chained calls. Of course another alternative is writing your code in a more |
| 62 | testable way in the first place... |
| 63 | |
| 64 | So, suppose we have some code that looks a little bit like this: |
| 65 | |
| 66 | .. doctest:: |
| 67 | |
| 68 | >>> class Something(object): |
| 69 | ... def __init__(self): |
| 70 | ... self.backend = BackendProvider() |
| 71 | ... def method(self): |
| 72 | ... response = self.backend.get_endpoint('foobar').create_call('spam', 'eggs').start_call() |
| 73 | ... # more code |
| 74 | |
| 75 | Assuming that `BackendProvider` is already well tested, how do we test |
| 76 | `method()`? Specifically, we want to test that the code section `# more |
| 77 | code` uses the response object in the correct way. |
| 78 | |
| 79 | As this chain of calls is made from an instance attribute we can monkey patch |
| 80 | the `backend` attribute on a `Something` instance. In this particular case |
| 81 | we are only interested in the return value from the final call to |
| 82 | `start_call` so we don't have much configuration to do. Let's assume the |
| 83 | object it returns is 'file-like', so we'll ensure that our response object |
| 84 | uses the builtin `file` as its `spec`. |
| 85 | |
| 86 | To do this we create a mock instance as our mock backend and create a mock |
| 87 | response object for it. To set the response as the return value for that final |
| 88 | `start_call` we could do this: |
| 89 | |
| 90 | `mock_backend.get_endpoint.return_value.create_call.return_value.start_call.return_value = mock_response`. |
| 91 | |
Michael Foord | b0a12be | 2012-03-05 13:05:21 +0000 | [diff] [blame] | 92 | We can do that in a slightly nicer way using the :meth:`~Mock.configure_mock` |
| 93 | method to directly set the return value for us: |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 94 | |
| 95 | .. doctest:: |
| 96 | |
| 97 | >>> something = Something() |
| 98 | >>> mock_response = Mock(spec=file) |
| 99 | >>> mock_backend = Mock() |
Michael Foord | b0a12be | 2012-03-05 13:05:21 +0000 | [diff] [blame] | 100 | >>> config = {'get_endpoint.return_value.create_call.return_value.start_call.return_value': mock_response} |
| 101 | >>> mock_backend.configure_mock(**config) |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 102 | |
| 103 | With these we monkey patch the "mock backend" in place and can make the real |
| 104 | call: |
| 105 | |
| 106 | .. doctest:: |
| 107 | |
| 108 | >>> something.backend = mock_backend |
| 109 | >>> something.method() |
| 110 | |
| 111 | Using :attr:`~Mock.mock_calls` we can check the chained call with a single |
| 112 | assert. A chained call is several calls in one line of code, so there will be |
| 113 | several entries in `mock_calls`. We can use :meth:`call.call_list` to create |
| 114 | this list of calls for us: |
| 115 | |
| 116 | .. doctest:: |
| 117 | |
| 118 | >>> chained = call.get_endpoint('foobar').create_call('spam', 'eggs').start_call() |
| 119 | >>> call_list = chained.call_list() |
| 120 | >>> assert mock_backend.mock_calls == call_list |
| 121 | |
| 122 | |
| 123 | Partial mocking |
| 124 | =============== |
| 125 | |
| 126 | In some tests I wanted to mock out a call to `datetime.date.today() |
| 127 | <http://docs.python.org/library/datetime.html#datetime.date.today>`_ to return |
| 128 | a known date, but I didn't want to prevent the code under test from |
| 129 | creating new date objects. Unfortunately `datetime.date` is written in C, and |
| 130 | so I couldn't just monkey-patch out the static `date.today` method. |
| 131 | |
| 132 | I found a simple way of doing this that involved effectively wrapping the date |
| 133 | class with a mock, but passing through calls to the constructor to the real |
| 134 | class (and returning real instances). |
| 135 | |
| 136 | The :func:`patch decorator <patch>` is used here to |
| 137 | mock out the `date` class in the module under test. The :attr:`side_effect` |
| 138 | attribute on the mock date class is then set to a lambda function that returns |
| 139 | a real date. When the mock date class is called a real date will be |
| 140 | constructed and returned by `side_effect`. |
| 141 | |
| 142 | .. doctest:: |
| 143 | |
| 144 | >>> from datetime import date |
| 145 | >>> with patch('mymodule.date') as mock_date: |
| 146 | ... mock_date.today.return_value = date(2010, 10, 8) |
| 147 | ... mock_date.side_effect = lambda *args, **kw: date(*args, **kw) |
| 148 | ... |
| 149 | ... assert mymodule.date.today() == date(2010, 10, 8) |
| 150 | ... assert mymodule.date(2009, 6, 8) == date(2009, 6, 8) |
| 151 | ... |
| 152 | |
| 153 | Note that we don't patch `datetime.date` globally, we patch `date` in the |
| 154 | module that *uses* it. See :ref:`where to patch <where-to-patch>`. |
| 155 | |
| 156 | When `date.today()` is called a known date is returned, but calls to the |
| 157 | `date(...)` constructor still return normal dates. Without this you can find |
| 158 | yourself having to calculate an expected result using exactly the same |
| 159 | algorithm as the code under test, which is a classic testing anti-pattern. |
| 160 | |
| 161 | Calls to the date constructor are recorded in the `mock_date` attributes |
| 162 | (`call_count` and friends) which may also be useful for your tests. |
| 163 | |
| 164 | An alternative way of dealing with mocking dates, or other builtin classes, |
| 165 | is discussed in `this blog entry |
| 166 | <http://williamjohnbert.com/2011/07/how-to-unit-testing-in-django-with-mocking-and-patching/>`_. |
| 167 | |
| 168 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 169 | Mocking a Generator Method |
| 170 | ========================== |
| 171 | |
| 172 | A Python generator is a function or method that uses the `yield statement |
| 173 | <http://docs.python.org/reference/simple_stmts.html#the-yield-statement>`_ to |
| 174 | return a series of values when iterated over [#]_. |
| 175 | |
| 176 | A generator method / function is called to return the generator object. It is |
| 177 | the generator object that is then iterated over. The protocol method for |
| 178 | iteration is `__iter__ |
| 179 | <http://docs.python.org/library/stdtypes.html#container.__iter__>`_, so we can |
| 180 | mock this using a `MagicMock`. |
| 181 | |
| 182 | Here's an example class with an "iter" method implemented as a generator: |
| 183 | |
| 184 | .. doctest:: |
| 185 | |
| 186 | >>> class Foo(object): |
| 187 | ... def iter(self): |
| 188 | ... for i in [1, 2, 3]: |
| 189 | ... yield i |
| 190 | ... |
| 191 | >>> foo = Foo() |
| 192 | >>> list(foo.iter()) |
| 193 | [1, 2, 3] |
| 194 | |
| 195 | |
| 196 | How would we mock this class, and in particular its "iter" method? |
| 197 | |
| 198 | To configure the values returned from the iteration (implicit in the call to |
| 199 | `list`), we need to configure the object returned by the call to `foo.iter()`. |
| 200 | |
| 201 | .. doctest:: |
| 202 | |
| 203 | >>> mock_foo = MagicMock() |
| 204 | >>> mock_foo.iter.return_value = iter([1, 2, 3]) |
| 205 | >>> list(mock_foo.iter()) |
| 206 | [1, 2, 3] |
| 207 | |
| 208 | .. [#] There are also generator expressions and more `advanced uses |
| 209 | <http://www.dabeaz.com/coroutines/index.html>`_ of generators, but we aren't |
| 210 | concerned about them here. A very good introduction to generators and how |
| 211 | powerful they are is: `Generator Tricks for Systems Programmers |
| 212 | <http://www.dabeaz.com/generators/>`_. |
| 213 | |
| 214 | |
| 215 | Applying the same patch to every test method |
| 216 | ============================================ |
| 217 | |
| 218 | If you want several patches in place for multiple test methods the obvious way |
| 219 | is to apply the patch decorators to every method. This can feel like unnecessary |
| 220 | repetition. For Python 2.6 or more recent you can use `patch` (in all its |
| 221 | various forms) as a class decorator. This applies the patches to all test |
| 222 | methods on the class. A test method is identified by methods whose names start |
| 223 | with `test`: |
| 224 | |
| 225 | .. doctest:: |
| 226 | |
| 227 | >>> @patch('mymodule.SomeClass') |
| 228 | ... class MyTest(TestCase): |
| 229 | ... |
| 230 | ... def test_one(self, MockSomeClass): |
| 231 | ... self.assertTrue(mymodule.SomeClass is MockSomeClass) |
| 232 | ... |
| 233 | ... def test_two(self, MockSomeClass): |
| 234 | ... self.assertTrue(mymodule.SomeClass is MockSomeClass) |
| 235 | ... |
| 236 | ... def not_a_test(self): |
| 237 | ... return 'something' |
| 238 | ... |
| 239 | >>> MyTest('test_one').test_one() |
| 240 | >>> MyTest('test_two').test_two() |
| 241 | >>> MyTest('test_two').not_a_test() |
| 242 | 'something' |
| 243 | |
| 244 | An alternative way of managing patches is to use the :ref:`start-and-stop`. |
| 245 | These allow you to move the patching into your `setUp` and `tearDown` methods. |
| 246 | |
| 247 | .. doctest:: |
| 248 | |
| 249 | >>> class MyTest(TestCase): |
| 250 | ... def setUp(self): |
| 251 | ... self.patcher = patch('mymodule.foo') |
| 252 | ... self.mock_foo = self.patcher.start() |
| 253 | ... |
| 254 | ... def test_foo(self): |
| 255 | ... self.assertTrue(mymodule.foo is self.mock_foo) |
| 256 | ... |
| 257 | ... def tearDown(self): |
| 258 | ... self.patcher.stop() |
| 259 | ... |
| 260 | >>> MyTest('test_foo').run() |
| 261 | |
| 262 | If you use this technique you must ensure that the patching is "undone" by |
| 263 | calling `stop`. This can be fiddlier than you might think, because if an |
| 264 | exception is raised in the setUp then tearDown is not called. `unittest2 |
| 265 | <http://pypi.python.org/pypi/unittest2>`_ cleanup functions make this simpler: |
| 266 | |
| 267 | |
| 268 | .. doctest:: |
| 269 | |
| 270 | >>> class MyTest(TestCase): |
| 271 | ... def setUp(self): |
| 272 | ... patcher = patch('mymodule.foo') |
| 273 | ... self.addCleanup(patcher.stop) |
| 274 | ... self.mock_foo = patcher.start() |
| 275 | ... |
| 276 | ... def test_foo(self): |
| 277 | ... self.assertTrue(mymodule.foo is self.mock_foo) |
| 278 | ... |
| 279 | >>> MyTest('test_foo').run() |
| 280 | |
| 281 | |
| 282 | Mocking Unbound Methods |
| 283 | ======================= |
| 284 | |
| 285 | Whilst writing tests today I needed to patch an *unbound method* (patching the |
| 286 | method on the class rather than on the instance). I needed self to be passed |
| 287 | in as the first argument because I want to make asserts about which objects |
| 288 | were calling this particular method. The issue is that you can't patch with a |
| 289 | mock for this, because if you replace an unbound method with a mock it doesn't |
| 290 | become a bound method when fetched from the instance, and so it doesn't get |
| 291 | self passed in. The workaround is to patch the unbound method with a real |
| 292 | function instead. The :func:`patch` decorator makes it so simple to |
| 293 | patch out methods with a mock that having to create a real function becomes a |
| 294 | nuisance. |
| 295 | |
Michael Foord | af78a50 | 2012-03-13 17:00:04 -0700 | [diff] [blame] | 296 | If you pass `autospec=True` to patch then it does the patching with a |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 297 | *real* function object. This function object has the same signature as the one |
| 298 | it is replacing, but delegates to a mock under the hood. You still get your |
| 299 | mock auto-created in exactly the same way as before. What it means though, is |
| 300 | that if you use it to patch out an unbound method on a class the mocked |
| 301 | function will be turned into a bound method if it is fetched from an instance. |
| 302 | It will have `self` passed in as the first argument, which is exactly what I |
| 303 | wanted: |
| 304 | |
| 305 | .. doctest:: |
| 306 | |
| 307 | >>> class Foo(object): |
| 308 | ... def foo(self): |
| 309 | ... pass |
| 310 | ... |
Michael Foord | af78a50 | 2012-03-13 17:00:04 -0700 | [diff] [blame] | 311 | >>> with patch.object(Foo, 'foo', autospec=True) as mock_foo: |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 312 | ... mock_foo.return_value = 'foo' |
| 313 | ... foo = Foo() |
| 314 | ... foo.foo() |
| 315 | ... |
| 316 | 'foo' |
| 317 | >>> mock_foo.assert_called_once_with(foo) |
| 318 | |
Michael Foord | af78a50 | 2012-03-13 17:00:04 -0700 | [diff] [blame] | 319 | If we don't use `autospec=True` then the unbound method is patched out |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 320 | with a Mock instance instead, and isn't called with `self`. |
| 321 | |
| 322 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 323 | Checking multiple calls with mock |
| 324 | ================================= |
| 325 | |
| 326 | mock has a nice API for making assertions about how your mock objects are used. |
| 327 | |
| 328 | .. doctest:: |
| 329 | |
| 330 | >>> mock = Mock() |
| 331 | >>> mock.foo_bar.return_value = None |
| 332 | >>> mock.foo_bar('baz', spam='eggs') |
| 333 | >>> mock.foo_bar.assert_called_with('baz', spam='eggs') |
| 334 | |
| 335 | If your mock is only being called once you can use the |
| 336 | :meth:`assert_called_once_with` method that also asserts that the |
| 337 | :attr:`call_count` is one. |
| 338 | |
| 339 | .. doctest:: |
| 340 | |
| 341 | >>> mock.foo_bar.assert_called_once_with('baz', spam='eggs') |
| 342 | >>> mock.foo_bar() |
| 343 | >>> mock.foo_bar.assert_called_once_with('baz', spam='eggs') |
| 344 | Traceback (most recent call last): |
| 345 | ... |
| 346 | AssertionError: Expected to be called once. Called 2 times. |
| 347 | |
| 348 | Both `assert_called_with` and `assert_called_once_with` make assertions about |
| 349 | the *most recent* call. If your mock is going to be called several times, and |
| 350 | you want to make assertions about *all* those calls you can use |
| 351 | :attr:`~Mock.call_args_list`: |
| 352 | |
| 353 | .. doctest:: |
| 354 | |
| 355 | >>> mock = Mock(return_value=None) |
| 356 | >>> mock(1, 2, 3) |
| 357 | >>> mock(4, 5, 6) |
| 358 | >>> mock() |
| 359 | >>> mock.call_args_list |
| 360 | [call(1, 2, 3), call(4, 5, 6), call()] |
| 361 | |
| 362 | The :data:`call` helper makes it easy to make assertions about these calls. You |
| 363 | can build up a list of expected calls and compare it to `call_args_list`. This |
| 364 | looks remarkably similar to the repr of the `call_args_list`: |
| 365 | |
| 366 | .. doctest:: |
| 367 | |
| 368 | >>> expected = [call(1, 2, 3), call(4, 5, 6), call()] |
| 369 | >>> mock.call_args_list == expected |
| 370 | True |
| 371 | |
| 372 | |
| 373 | Coping with mutable arguments |
| 374 | ============================= |
| 375 | |
| 376 | Another situation is rare, but can bite you, is when your mock is called with |
| 377 | mutable arguments. `call_args` and `call_args_list` store *references* to the |
| 378 | arguments. If the arguments are mutated by the code under test then you can no |
| 379 | longer make assertions about what the values were when the mock was called. |
| 380 | |
| 381 | Here's some example code that shows the problem. Imagine the following functions |
| 382 | defined in 'mymodule':: |
| 383 | |
| 384 | def frob(val): |
| 385 | pass |
| 386 | |
| 387 | def grob(val): |
| 388 | "First frob and then clear val" |
| 389 | frob(val) |
| 390 | val.clear() |
| 391 | |
| 392 | When we try to test that `grob` calls `frob` with the correct argument look |
| 393 | what happens: |
| 394 | |
| 395 | .. doctest:: |
| 396 | |
| 397 | >>> with patch('mymodule.frob') as mock_frob: |
| 398 | ... val = set([6]) |
| 399 | ... mymodule.grob(val) |
| 400 | ... |
| 401 | >>> val |
| 402 | set([]) |
| 403 | >>> mock_frob.assert_called_with(set([6])) |
| 404 | Traceback (most recent call last): |
| 405 | ... |
| 406 | AssertionError: Expected: ((set([6]),), {}) |
| 407 | Called with: ((set([]),), {}) |
| 408 | |
| 409 | One possibility would be for mock to copy the arguments you pass in. This |
| 410 | could then cause problems if you do assertions that rely on object identity |
| 411 | for equality. |
| 412 | |
| 413 | Here's one solution that uses the :attr:`side_effect` |
| 414 | functionality. If you provide a `side_effect` function for a mock then |
| 415 | `side_effect` will be called with the same args as the mock. This gives us an |
| 416 | opportunity to copy the arguments and store them for later assertions. In this |
| 417 | example I'm using *another* mock to store the arguments so that I can use the |
| 418 | mock methods for doing the assertion. Again a helper function sets this up for |
| 419 | me. |
| 420 | |
| 421 | .. doctest:: |
| 422 | |
| 423 | >>> from copy import deepcopy |
| 424 | >>> from mock import Mock, patch, DEFAULT |
| 425 | >>> def copy_call_args(mock): |
| 426 | ... new_mock = Mock() |
| 427 | ... def side_effect(*args, **kwargs): |
| 428 | ... args = deepcopy(args) |
| 429 | ... kwargs = deepcopy(kwargs) |
| 430 | ... new_mock(*args, **kwargs) |
| 431 | ... return DEFAULT |
| 432 | ... mock.side_effect = side_effect |
| 433 | ... return new_mock |
| 434 | ... |
| 435 | >>> with patch('mymodule.frob') as mock_frob: |
| 436 | ... new_mock = copy_call_args(mock_frob) |
| 437 | ... val = set([6]) |
| 438 | ... mymodule.grob(val) |
| 439 | ... |
| 440 | >>> new_mock.assert_called_with(set([6])) |
| 441 | >>> new_mock.call_args |
| 442 | call(set([6])) |
| 443 | |
| 444 | `copy_call_args` is called with the mock that will be called. It returns a new |
| 445 | mock that we do the assertion on. The `side_effect` function makes a copy of |
| 446 | the args and calls our `new_mock` with the copy. |
| 447 | |
| 448 | .. note:: |
| 449 | |
| 450 | If your mock is only going to be used once there is an easier way of |
| 451 | checking arguments at the point they are called. You can simply do the |
| 452 | checking inside a `side_effect` function. |
| 453 | |
| 454 | .. doctest:: |
| 455 | |
| 456 | >>> def side_effect(arg): |
| 457 | ... assert arg == set([6]) |
| 458 | ... |
| 459 | >>> mock = Mock(side_effect=side_effect) |
| 460 | >>> mock(set([6])) |
| 461 | >>> mock(set()) |
| 462 | Traceback (most recent call last): |
| 463 | ... |
| 464 | AssertionError |
| 465 | |
| 466 | An alternative approach is to create a subclass of `Mock` or `MagicMock` that |
| 467 | copies (using `copy.deepcopy |
| 468 | <http://docs.python.org/library/copy.html#copy.deepcopy>`_) the arguments. |
| 469 | Here's an example implementation: |
| 470 | |
| 471 | .. doctest:: |
| 472 | |
| 473 | >>> from copy import deepcopy |
| 474 | >>> class CopyingMock(MagicMock): |
| 475 | ... def __call__(self, *args, **kwargs): |
| 476 | ... args = deepcopy(args) |
| 477 | ... kwargs = deepcopy(kwargs) |
| 478 | ... return super(CopyingMock, self).__call__(*args, **kwargs) |
| 479 | ... |
| 480 | >>> c = CopyingMock(return_value=None) |
| 481 | >>> arg = set() |
| 482 | >>> c(arg) |
| 483 | >>> arg.add(1) |
| 484 | >>> c.assert_called_with(set()) |
| 485 | >>> c.assert_called_with(arg) |
| 486 | Traceback (most recent call last): |
| 487 | ... |
| 488 | AssertionError: Expected call: mock(set([1])) |
| 489 | Actual call: mock(set([])) |
| 490 | >>> c.foo |
| 491 | <CopyingMock name='mock.foo' id='...'> |
| 492 | |
| 493 | When you subclass `Mock` or `MagicMock` all dynamically created attributes, |
| 494 | and the `return_value` will use your subclass automatically. That means all |
| 495 | children of a `CopyingMock` will also have the type `CopyingMock`. |
| 496 | |
| 497 | |
Michael Foord | 3978796 | 2012-04-23 12:10:24 +0100 | [diff] [blame] | 498 | Raising exceptions on attribute access |
| 499 | ====================================== |
| 500 | |
| 501 | You can use :class:`PropertyMock` to mimic the behaviour of properties. This |
| 502 | includes raising exceptions when an attribute is accessed. |
| 503 | |
| 504 | Here's an example raising a `ValueError` when the 'foo' attribute is accessed: |
| 505 | |
| 506 | .. doctest:: |
| 507 | |
| 508 | >>> m = MagicMock() |
| 509 | >>> p = PropertyMock(side_effect=ValueError) |
| 510 | >>> type(m).foo = p |
| 511 | >>> m.foo |
| 512 | Traceback (most recent call last): |
| 513 | .... |
| 514 | ValueError |
| 515 | |
| 516 | Because every mock object has its own type, a new subclass of whichever mock |
| 517 | class you're using, all mock objects are isolated from each other. You can |
| 518 | safely attach properties (or other descriptors or whatever you want in fact) |
| 519 | to `type(mock)` without affecting other mock objects. |
| 520 | |
| 521 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 522 | Multiple calls with different effects |
| 523 | ===================================== |
| 524 | |
Michael Foord | 70b4ef6 | 2012-04-21 01:44:18 +0100 | [diff] [blame] | 525 | .. note:: |
| 526 | |
| 527 | In mock 1.0 the handling of iterable `side_effect` was changed. Any |
| 528 | exceptions in the iterable will be raised instead of returned. |
| 529 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 530 | Handling code that needs to behave differently on subsequent calls during the |
| 531 | test can be tricky. For example you may have a function that needs to raise |
| 532 | an exception the first time it is called but returns a response on the second |
| 533 | call (testing retry behaviour). |
| 534 | |
| 535 | One approach is to use a :attr:`side_effect` function that replaces itself. The |
| 536 | first time it is called the `side_effect` sets a new `side_effect` that will |
| 537 | be used for the second call. It then raises an exception: |
| 538 | |
| 539 | .. doctest:: |
| 540 | |
| 541 | >>> def side_effect(*args): |
| 542 | ... def second_call(*args): |
| 543 | ... return 'response' |
| 544 | ... mock.side_effect = second_call |
| 545 | ... raise Exception('boom') |
| 546 | ... |
| 547 | >>> mock = Mock(side_effect=side_effect) |
| 548 | >>> mock('first') |
| 549 | Traceback (most recent call last): |
| 550 | ... |
| 551 | Exception: boom |
| 552 | >>> mock('second') |
| 553 | 'response' |
| 554 | >>> mock.assert_called_with('second') |
| 555 | |
| 556 | Another perfectly valid way would be to pop return values from a list. If the |
| 557 | return value is an exception, raise it instead of returning it: |
| 558 | |
| 559 | .. doctest:: |
| 560 | |
| 561 | >>> returns = [Exception('boom'), 'response'] |
| 562 | >>> def side_effect(*args): |
| 563 | ... result = returns.pop(0) |
| 564 | ... if isinstance(result, Exception): |
| 565 | ... raise result |
| 566 | ... return result |
| 567 | ... |
| 568 | >>> mock = Mock(side_effect=side_effect) |
| 569 | >>> mock('first') |
| 570 | Traceback (most recent call last): |
| 571 | ... |
| 572 | Exception: boom |
| 573 | >>> mock('second') |
| 574 | 'response' |
| 575 | >>> mock.assert_called_with('second') |
| 576 | |
| 577 | Which approach you prefer is a matter of taste. The first approach is actually |
| 578 | a line shorter but maybe the second approach is more readable. |
| 579 | |
| 580 | |
| 581 | Nesting Patches |
| 582 | =============== |
| 583 | |
| 584 | Using patch as a context manager is nice, but if you do multiple patches you |
| 585 | can end up with nested with statements indenting further and further to the |
| 586 | right: |
| 587 | |
| 588 | .. doctest:: |
| 589 | |
| 590 | >>> class MyTest(TestCase): |
| 591 | ... |
| 592 | ... def test_foo(self): |
| 593 | ... with patch('mymodule.Foo') as mock_foo: |
| 594 | ... with patch('mymodule.Bar') as mock_bar: |
| 595 | ... with patch('mymodule.Spam') as mock_spam: |
| 596 | ... assert mymodule.Foo is mock_foo |
| 597 | ... assert mymodule.Bar is mock_bar |
| 598 | ... assert mymodule.Spam is mock_spam |
| 599 | ... |
| 600 | >>> original = mymodule.Foo |
| 601 | >>> MyTest('test_foo').test_foo() |
| 602 | >>> assert mymodule.Foo is original |
| 603 | |
| 604 | With unittest2_ `cleanup` functions and the :ref:`start-and-stop` we can |
| 605 | achieve the same effect without the nested indentation. A simple helper |
| 606 | method, `create_patch`, puts the patch in place and returns the created mock |
| 607 | for us: |
| 608 | |
| 609 | .. doctest:: |
| 610 | |
| 611 | >>> class MyTest(TestCase): |
| 612 | ... |
| 613 | ... def create_patch(self, name): |
| 614 | ... patcher = patch(name) |
| 615 | ... thing = patcher.start() |
| 616 | ... self.addCleanup(patcher.stop) |
| 617 | ... return thing |
| 618 | ... |
| 619 | ... def test_foo(self): |
| 620 | ... mock_foo = self.create_patch('mymodule.Foo') |
| 621 | ... mock_bar = self.create_patch('mymodule.Bar') |
| 622 | ... mock_spam = self.create_patch('mymodule.Spam') |
| 623 | ... |
| 624 | ... assert mymodule.Foo is mock_foo |
| 625 | ... assert mymodule.Bar is mock_bar |
| 626 | ... assert mymodule.Spam is mock_spam |
| 627 | ... |
| 628 | >>> original = mymodule.Foo |
| 629 | >>> MyTest('test_foo').run() |
| 630 | >>> assert mymodule.Foo is original |
| 631 | |
| 632 | |
| 633 | Mocking a dictionary with MagicMock |
| 634 | =================================== |
| 635 | |
| 636 | You may want to mock a dictionary, or other container object, recording all |
| 637 | access to it whilst having it still behave like a dictionary. |
| 638 | |
| 639 | We can do this with :class:`MagicMock`, which will behave like a dictionary, |
| 640 | and using :data:`~Mock.side_effect` to delegate dictionary access to a real |
| 641 | underlying dictionary that is under our control. |
| 642 | |
| 643 | When the `__getitem__` and `__setitem__` methods of our `MagicMock` are called |
| 644 | (normal dictionary access) then `side_effect` is called with the key (and in |
| 645 | the case of `__setitem__` the value too). We can also control what is returned. |
| 646 | |
| 647 | After the `MagicMock` has been used we can use attributes like |
| 648 | :data:`~Mock.call_args_list` to assert about how the dictionary was used: |
| 649 | |
| 650 | .. doctest:: |
| 651 | |
| 652 | >>> my_dict = {'a': 1, 'b': 2, 'c': 3} |
| 653 | >>> def getitem(name): |
| 654 | ... return my_dict[name] |
| 655 | ... |
| 656 | >>> def setitem(name, val): |
| 657 | ... my_dict[name] = val |
| 658 | ... |
| 659 | >>> mock = MagicMock() |
| 660 | >>> mock.__getitem__.side_effect = getitem |
| 661 | >>> mock.__setitem__.side_effect = setitem |
| 662 | |
| 663 | .. note:: |
| 664 | |
| 665 | An alternative to using `MagicMock` is to use `Mock` and *only* provide |
| 666 | the magic methods you specifically want: |
| 667 | |
| 668 | .. doctest:: |
| 669 | |
| 670 | >>> mock = Mock() |
| 671 | >>> mock.__setitem__ = Mock(side_effect=getitem) |
| 672 | >>> mock.__getitem__ = Mock(side_effect=setitem) |
| 673 | |
| 674 | A *third* option is to use `MagicMock` but passing in `dict` as the `spec` |
| 675 | (or `spec_set`) argument so that the `MagicMock` created only has |
| 676 | dictionary magic methods available: |
| 677 | |
| 678 | .. doctest:: |
| 679 | |
| 680 | >>> mock = MagicMock(spec_set=dict) |
| 681 | >>> mock.__getitem__.side_effect = getitem |
| 682 | >>> mock.__setitem__.side_effect = setitem |
| 683 | |
| 684 | With these side effect functions in place, the `mock` will behave like a normal |
| 685 | dictionary but recording the access. It even raises a `KeyError` if you try |
| 686 | to access a key that doesn't exist. |
| 687 | |
| 688 | .. doctest:: |
| 689 | |
| 690 | >>> mock['a'] |
| 691 | 1 |
| 692 | >>> mock['c'] |
| 693 | 3 |
| 694 | >>> mock['d'] |
| 695 | Traceback (most recent call last): |
| 696 | ... |
| 697 | KeyError: 'd' |
| 698 | >>> mock['b'] = 'fish' |
| 699 | >>> mock['d'] = 'eggs' |
| 700 | >>> mock['b'] |
| 701 | 'fish' |
| 702 | >>> mock['d'] |
| 703 | 'eggs' |
| 704 | |
| 705 | After it has been used you can make assertions about the access using the normal |
| 706 | mock methods and attributes: |
| 707 | |
| 708 | .. doctest:: |
| 709 | |
| 710 | >>> mock.__getitem__.call_args_list |
| 711 | [call('a'), call('c'), call('d'), call('b'), call('d')] |
| 712 | >>> mock.__setitem__.call_args_list |
| 713 | [call('b', 'fish'), call('d', 'eggs')] |
| 714 | >>> my_dict |
| 715 | {'a': 1, 'c': 3, 'b': 'fish', 'd': 'eggs'} |
| 716 | |
| 717 | |
| 718 | Mock subclasses and their attributes |
| 719 | ==================================== |
| 720 | |
| 721 | There are various reasons why you might want to subclass `Mock`. One reason |
| 722 | might be to add helper methods. Here's a silly example: |
| 723 | |
| 724 | .. doctest:: |
| 725 | |
| 726 | >>> class MyMock(MagicMock): |
| 727 | ... def has_been_called(self): |
| 728 | ... return self.called |
| 729 | ... |
| 730 | >>> mymock = MyMock(return_value=None) |
| 731 | >>> mymock |
| 732 | <MyMock id='...'> |
| 733 | >>> mymock.has_been_called() |
| 734 | False |
| 735 | >>> mymock() |
| 736 | >>> mymock.has_been_called() |
| 737 | True |
| 738 | |
| 739 | The standard behaviour for `Mock` instances is that attributes and the return |
| 740 | value mocks are of the same type as the mock they are accessed on. This ensures |
| 741 | that `Mock` attributes are `Mocks` and `MagicMock` attributes are `MagicMocks` |
| 742 | [#]_. So if you're subclassing to add helper methods then they'll also be |
| 743 | available on the attributes and return value mock of instances of your |
| 744 | subclass. |
| 745 | |
| 746 | .. doctest:: |
| 747 | |
| 748 | >>> mymock.foo |
| 749 | <MyMock name='mock.foo' id='...'> |
| 750 | >>> mymock.foo.has_been_called() |
| 751 | False |
| 752 | >>> mymock.foo() |
| 753 | <MyMock name='mock.foo()' id='...'> |
| 754 | >>> mymock.foo.has_been_called() |
| 755 | True |
| 756 | |
| 757 | Sometimes this is inconvenient. For example, `one user |
| 758 | <https://code.google.com/p/mock/issues/detail?id=105>`_ is subclassing mock to |
| 759 | created a `Twisted adaptor |
| 760 | <http://twistedmatrix.com/documents/11.0.0/api/twisted.python.components.html>`_. |
| 761 | Having this applied to attributes too actually causes errors. |
| 762 | |
| 763 | `Mock` (in all its flavours) uses a method called `_get_child_mock` to create |
| 764 | these "sub-mocks" for attributes and return values. You can prevent your |
| 765 | subclass being used for attributes by overriding this method. The signature is |
| 766 | that it takes arbitrary keyword arguments (`**kwargs`) which are then passed |
| 767 | onto the mock constructor: |
| 768 | |
| 769 | .. doctest:: |
| 770 | |
| 771 | >>> class Subclass(MagicMock): |
| 772 | ... def _get_child_mock(self, **kwargs): |
| 773 | ... return MagicMock(**kwargs) |
| 774 | ... |
| 775 | >>> mymock = Subclass() |
| 776 | >>> mymock.foo |
| 777 | <MagicMock name='mock.foo' id='...'> |
| 778 | >>> assert isinstance(mymock, Subclass) |
| 779 | >>> assert not isinstance(mymock.foo, Subclass) |
| 780 | >>> assert not isinstance(mymock(), Subclass) |
| 781 | |
| 782 | .. [#] An exception to this rule are the non-callable mocks. Attributes use the |
| 783 | callable variant because otherwise non-callable mocks couldn't have callable |
| 784 | methods. |
| 785 | |
| 786 | |
| 787 | Mocking imports with patch.dict |
| 788 | =============================== |
| 789 | |
| 790 | One situation where mocking can be hard is where you have a local import inside |
| 791 | a function. These are harder to mock because they aren't using an object from |
| 792 | the module namespace that we can patch out. |
| 793 | |
| 794 | Generally local imports are to be avoided. They are sometimes done to prevent |
| 795 | circular dependencies, for which there is *usually* a much better way to solve |
| 796 | the problem (refactor the code) or to prevent "up front costs" by delaying the |
| 797 | import. This can also be solved in better ways than an unconditional local |
| 798 | import (store the module as a class or module attribute and only do the import |
| 799 | on first use). |
| 800 | |
| 801 | That aside there is a way to use `mock` to affect the results of an import. |
| 802 | Importing fetches an *object* from the `sys.modules` dictionary. Note that it |
| 803 | fetches an *object*, which need not be a module. Importing a module for the |
| 804 | first time results in a module object being put in `sys.modules`, so usually |
| 805 | when you import something you get a module back. This need not be the case |
| 806 | however. |
| 807 | |
| 808 | This means you can use :func:`patch.dict` to *temporarily* put a mock in place |
| 809 | in `sys.modules`. Any imports whilst this patch is active will fetch the mock. |
| 810 | When the patch is complete (the decorated function exits, the with statement |
| 811 | body is complete or `patcher.stop()` is called) then whatever was there |
| 812 | previously will be restored safely. |
| 813 | |
| 814 | Here's an example that mocks out the 'fooble' module. |
| 815 | |
| 816 | .. doctest:: |
| 817 | |
| 818 | >>> mock = Mock() |
| 819 | >>> with patch.dict('sys.modules', {'fooble': mock}): |
| 820 | ... import fooble |
| 821 | ... fooble.blob() |
| 822 | ... |
| 823 | <Mock name='mock.blob()' id='...'> |
| 824 | >>> assert 'fooble' not in sys.modules |
| 825 | >>> mock.blob.assert_called_once_with() |
| 826 | |
| 827 | As you can see the `import fooble` succeeds, but on exit there is no 'fooble' |
| 828 | left in `sys.modules`. |
| 829 | |
| 830 | This also works for the `from module import name` form: |
| 831 | |
| 832 | .. doctest:: |
| 833 | |
| 834 | >>> mock = Mock() |
| 835 | >>> with patch.dict('sys.modules', {'fooble': mock}): |
| 836 | ... from fooble import blob |
| 837 | ... blob.blip() |
| 838 | ... |
| 839 | <Mock name='mock.blob.blip()' id='...'> |
| 840 | >>> mock.blob.blip.assert_called_once_with() |
| 841 | |
| 842 | With slightly more work you can also mock package imports: |
| 843 | |
| 844 | .. doctest:: |
| 845 | |
| 846 | >>> mock = Mock() |
| 847 | >>> modules = {'package': mock, 'package.module': mock.module} |
| 848 | >>> with patch.dict('sys.modules', modules): |
| 849 | ... from package.module import fooble |
| 850 | ... fooble() |
| 851 | ... |
| 852 | <Mock name='mock.module.fooble()' id='...'> |
| 853 | >>> mock.module.fooble.assert_called_once_with() |
| 854 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 855 | |
| 856 | Tracking order of calls and less verbose call assertions |
| 857 | ======================================================== |
| 858 | |
| 859 | The :class:`Mock` class allows you to track the *order* of method calls on |
| 860 | your mock objects through the :attr:`~Mock.method_calls` attribute. This |
| 861 | doesn't allow you to track the order of calls between separate mock objects, |
| 862 | however we can use :attr:`~Mock.mock_calls` to achieve the same effect. |
| 863 | |
| 864 | Because mocks track calls to child mocks in `mock_calls`, and accessing an |
| 865 | arbitrary attribute of a mock creates a child mock, we can create our separate |
| 866 | mocks from a parent one. Calls to those child mock will then all be recorded, |
| 867 | in order, in the `mock_calls` of the parent: |
| 868 | |
| 869 | .. doctest:: |
| 870 | |
| 871 | >>> manager = Mock() |
| 872 | >>> mock_foo = manager.foo |
| 873 | >>> mock_bar = manager.bar |
| 874 | |
| 875 | >>> mock_foo.something() |
| 876 | <Mock name='mock.foo.something()' id='...'> |
| 877 | >>> mock_bar.other.thing() |
| 878 | <Mock name='mock.bar.other.thing()' id='...'> |
| 879 | |
| 880 | >>> manager.mock_calls |
| 881 | [call.foo.something(), call.bar.other.thing()] |
| 882 | |
| 883 | We can then assert about the calls, including the order, by comparing with |
| 884 | the `mock_calls` attribute on the manager mock: |
| 885 | |
| 886 | .. doctest:: |
| 887 | |
| 888 | >>> expected_calls = [call.foo.something(), call.bar.other.thing()] |
| 889 | >>> manager.mock_calls == expected_calls |
| 890 | True |
| 891 | |
| 892 | If `patch` is creating, and putting in place, your mocks then you can attach |
| 893 | them to a manager mock using the :meth:`~Mock.attach_mock` method. After |
| 894 | attaching calls will be recorded in `mock_calls` of the manager. |
| 895 | |
| 896 | .. doctest:: |
| 897 | |
| 898 | >>> manager = MagicMock() |
| 899 | >>> with patch('mymodule.Class1') as MockClass1: |
| 900 | ... with patch('mymodule.Class2') as MockClass2: |
| 901 | ... manager.attach_mock(MockClass1, 'MockClass1') |
| 902 | ... manager.attach_mock(MockClass2, 'MockClass2') |
| 903 | ... MockClass1().foo() |
| 904 | ... MockClass2().bar() |
| 905 | ... |
| 906 | <MagicMock name='mock.MockClass1().foo()' id='...'> |
| 907 | <MagicMock name='mock.MockClass2().bar()' id='...'> |
| 908 | >>> manager.mock_calls |
| 909 | [call.MockClass1(), |
| 910 | call.MockClass1().foo(), |
| 911 | call.MockClass2(), |
| 912 | call.MockClass2().bar()] |
| 913 | |
| 914 | If many calls have been made, but you're only interested in a particular |
| 915 | sequence of them then an alternative is to use the |
| 916 | :meth:`~Mock.assert_has_calls` method. This takes a list of calls (constructed |
| 917 | with the :data:`call` object). If that sequence of calls are in |
| 918 | :attr:`~Mock.mock_calls` then the assert succeeds. |
| 919 | |
| 920 | .. doctest:: |
| 921 | |
| 922 | >>> m = MagicMock() |
| 923 | >>> m().foo().bar().baz() |
| 924 | <MagicMock name='mock().foo().bar().baz()' id='...'> |
| 925 | >>> m.one().two().three() |
| 926 | <MagicMock name='mock.one().two().three()' id='...'> |
| 927 | >>> calls = call.one().two().three().call_list() |
| 928 | >>> m.assert_has_calls(calls) |
| 929 | |
| 930 | Even though the chained call `m.one().two().three()` aren't the only calls that |
| 931 | have been made to the mock, the assert still succeeds. |
| 932 | |
| 933 | Sometimes a mock may have several calls made to it, and you are only interested |
| 934 | in asserting about *some* of those calls. You may not even care about the |
| 935 | order. In this case you can pass `any_order=True` to `assert_has_calls`: |
| 936 | |
| 937 | .. doctest:: |
| 938 | |
| 939 | >>> m = MagicMock() |
| 940 | >>> m(1), m.two(2, 3), m.seven(7), m.fifty('50') |
| 941 | (...) |
| 942 | >>> calls = [call.fifty('50'), call(1), call.seven(7)] |
| 943 | >>> m.assert_has_calls(calls, any_order=True) |
| 944 | |
| 945 | |
| 946 | More complex argument matching |
| 947 | ============================== |
| 948 | |
| 949 | Using the same basic concept as `ANY` we can implement matchers to do more |
| 950 | complex assertions on objects used as arguments to mocks. |
| 951 | |
| 952 | Suppose we expect some object to be passed to a mock that by default |
| 953 | compares equal based on object identity (which is the Python default for user |
| 954 | defined classes). To use :meth:`~Mock.assert_called_with` we would need to pass |
| 955 | in the exact same object. If we are only interested in some of the attributes |
| 956 | of this object then we can create a matcher that will check these attributes |
| 957 | for us. |
| 958 | |
| 959 | You can see in this example how a 'standard' call to `assert_called_with` isn't |
| 960 | sufficient: |
| 961 | |
| 962 | .. doctest:: |
| 963 | |
| 964 | >>> class Foo(object): |
| 965 | ... def __init__(self, a, b): |
| 966 | ... self.a, self.b = a, b |
| 967 | ... |
| 968 | >>> mock = Mock(return_value=None) |
| 969 | >>> mock(Foo(1, 2)) |
| 970 | >>> mock.assert_called_with(Foo(1, 2)) |
| 971 | Traceback (most recent call last): |
| 972 | ... |
| 973 | AssertionError: Expected: call(<__main__.Foo object at 0x...>) |
| 974 | Actual call: call(<__main__.Foo object at 0x...>) |
| 975 | |
| 976 | A comparison function for our `Foo` class might look something like this: |
| 977 | |
| 978 | .. doctest:: |
| 979 | |
| 980 | >>> def compare(self, other): |
| 981 | ... if not type(self) == type(other): |
| 982 | ... return False |
| 983 | ... if self.a != other.a: |
| 984 | ... return False |
| 985 | ... if self.b != other.b: |
| 986 | ... return False |
| 987 | ... return True |
| 988 | ... |
| 989 | |
| 990 | And a matcher object that can use comparison functions like this for its |
| 991 | equality operation would look something like this: |
| 992 | |
| 993 | .. doctest:: |
| 994 | |
| 995 | >>> class Matcher(object): |
| 996 | ... def __init__(self, compare, some_obj): |
| 997 | ... self.compare = compare |
| 998 | ... self.some_obj = some_obj |
| 999 | ... def __eq__(self, other): |
| 1000 | ... return self.compare(self.some_obj, other) |
| 1001 | ... |
| 1002 | |
| 1003 | Putting all this together: |
| 1004 | |
| 1005 | .. doctest:: |
| 1006 | |
| 1007 | >>> match_foo = Matcher(compare, Foo(1, 2)) |
| 1008 | >>> mock.assert_called_with(match_foo) |
| 1009 | |
| 1010 | The `Matcher` is instantiated with our compare function and the `Foo` object |
| 1011 | we want to compare against. In `assert_called_with` the `Matcher` equality |
| 1012 | method will be called, which compares the object the mock was called with |
| 1013 | against the one we created our matcher with. If they match then |
| 1014 | `assert_called_with` passes, and if they don't an `AssertionError` is raised: |
| 1015 | |
| 1016 | .. doctest:: |
| 1017 | |
| 1018 | >>> match_wrong = Matcher(compare, Foo(3, 4)) |
| 1019 | >>> mock.assert_called_with(match_wrong) |
| 1020 | Traceback (most recent call last): |
| 1021 | ... |
| 1022 | AssertionError: Expected: ((<Matcher object at 0x...>,), {}) |
| 1023 | Called with: ((<Foo object at 0x...>,), {}) |
| 1024 | |
| 1025 | With a bit of tweaking you could have the comparison function raise the |
| 1026 | `AssertionError` directly and provide a more useful failure message. |
| 1027 | |
| 1028 | As of version 1.5, the Python testing library `PyHamcrest |
| 1029 | <http://pypi.python.org/pypi/PyHamcrest>`_ provides similar functionality, |
| 1030 | that may be useful here, in the form of its equality matcher |
| 1031 | (`hamcrest.library.integration.match_equality |
| 1032 | <http://packages.python.org/PyHamcrest/integration.html#hamcrest.library.integration.match_equality>`_). |
| 1033 | |
| 1034 | |
| 1035 | Less verbose configuration of mock objects |
| 1036 | ========================================== |
| 1037 | |
| 1038 | This recipe, for easier configuration of mock objects, is now part of `Mock`. |
| 1039 | See the :meth:`~Mock.configure_mock` method. |
| 1040 | |
| 1041 | |
Michael Foord | 1e68bec | 2012-03-03 22:24:30 +0000 | [diff] [blame] | 1042 | Matching any argument in assertions |
| 1043 | =================================== |
| 1044 | |
| 1045 | This example is now built in to mock. See :data:`ANY`. |
Michael Foord | 8e7aed5 | 2012-03-17 18:00:29 -0700 | [diff] [blame] | 1046 | |
| 1047 | |
| 1048 | Mocking Properties |
| 1049 | ================== |
| 1050 | |
| 1051 | This example is now built in to mock. See :class:`PropertyMock`. |
| 1052 | |
| 1053 | |
| 1054 | Mocking open |
| 1055 | ============ |
| 1056 | |
| 1057 | This example is now built in to mock. See :func:`mock_open`. |
| 1058 | |
| 1059 | |
| 1060 | Mocks without some attributes |
| 1061 | ============================= |
| 1062 | |
| 1063 | This example is now built in to mock. See :ref:`deleting-attributes`. |