The Tor Browser: python/mock-1.0.0/docs/getting-started.txt@b8a032363ba2 (annotated)

python/mock-1.0.0/docs/getting-started.txt@b8a032363ba2 (annotated)

python/mock-1.0.0/docs/getting-started.txt

Thu, 22 Jan 2015 13:21:57 +0100

author: Michael Schloh von Bennewitz <michael@schloh.com>
date: Thu, 22 Jan 2015 13:21:57 +0100
branch: TOR_BUG_9701
changeset 15: b8a032363ba2
permissions: -rw-r--r--

Incorporate requested changes from Mozilla in review:
https://bugzilla.mozilla.org/show_bug.cgi?id=1123480#c6

 ===========================
  Getting Started with Mock
 ===========================
 .. _getting-started:
 .. index:: Getting Started
 .. testsetup::
     class SomeClass(object):
         static_method = None
         class_method = None
         attribute = None
     sys.modules['package'] = package = Mock(name='package')
     sys.modules['package.module'] = module = package.module
     sys.modules['module'] = package.module
 Using Mock
 ==========
 Mock Patching Methods
 ---------------------
 Common uses for :class:`Mock` objects include:
 * Patching methods
 * Recording method calls on objects
 You might want to replace a method on an object to check that
 it is called with the correct arguments by another part of the system:
 .. doctest::
     >>> real = SomeClass()
     >>> real.method = MagicMock(name='method')
     >>> real.method(3, 4, 5, key='value')
     <MagicMock name='method()' id='...'>
 Once our mock has been used (`real.method` in this example) it has methods
 and attributes that allow you to make assertions about how it has been used.
 .. note::
     In most of these examples the :class:`Mock` and :class:`MagicMock` classes
     are interchangeable. As the `MagicMock` is the more capable class it makes
     a sensible one to use by default.
 Once the mock has been called its :attr:`~Mock.called` attribute is set to
 `True`. More importantly we can use the :meth:`~Mock.assert_called_with` or
 :meth:`~Mock.assert_called_once_with` method to check that it was called with
 the correct arguments.
 This example tests that calling `ProductionClass().method` results in a call to
 the `something` method:
 .. doctest::
     >>> from mock import MagicMock
     >>> class ProductionClass(object):
     ...     def method(self):
     ...         self.something(1, 2, 3)
     ...     def something(self, a, b, c):
     ...         pass
     ...
     >>> real = ProductionClass()
     >>> real.something = MagicMock()
     >>> real.method()
     >>> real.something.assert_called_once_with(1, 2, 3)
 Mock for Method Calls on an Object
 ----------------------------------
 In the last example we patched a method directly on an object to check that it
 was called correctly. Another common use case is to pass an object into a
 method (or some part of the system under test) and then check that it is used
 in the correct way.
 The simple `ProductionClass` below has a `closer` method. If it is called with
 an object then it calls `close` on it.
 .. doctest::
     >>> class ProductionClass(object):
     ...     def closer(self, something):
     ...         something.close()
     ...
 So to test it we need to pass in an object with a `close` method and check
 that it was called correctly.
 .. doctest::
     >>> real = ProductionClass()
     >>> mock = Mock()
     >>> real.closer(mock)
     >>> mock.close.assert_called_with()
 We don't have to do any work to provide the 'close' method on our mock.
 Accessing close creates it. So, if 'close' hasn't already been called then
 accessing it in the test will create it, but :meth:`~Mock.assert_called_with`
 will raise a failure exception.
 Mocking Classes
 ---------------
 A common use case is to mock out classes instantiated by your code under test.
 When you patch a class, then that class is replaced with a mock. Instances
 are created by *calling the class*. This means you access the "mock instance"
 by looking at the return value of the mocked class.
 In the example below we have a function `some_function` that instantiates `Foo`
 and calls a method on it. The call to `patch` replaces the class `Foo` with a
 mock. The `Foo` instance is the result of calling the mock, so it is configured
 by modifying the mock :attr:`~Mock.return_value`.
 .. doctest::
     >>> def some_function():
     ...     instance = module.Foo()
     ...     return instance.method()
     ...
     >>> with patch('module.Foo') as mock:
     ...     instance = mock.return_value
     ...     instance.method.return_value = 'the result'
     ...     result = some_function()
     ...     assert result == 'the result'
 Naming your mocks
 -----------------
 It can be useful to give your mocks a name. The name is shown in the repr of
 the mock and can be helpful when the mock appears in test failure messages. The
 name is also propagated to attributes or methods of the mock:
 .. doctest::
     >>> mock = MagicMock(name='foo')
     >>> mock
     <MagicMock name='foo' id='...'>
     >>> mock.method
     <MagicMock name='foo.method' id='...'>
 Tracking all Calls
 ------------------
 Often you want to track more than a single call to a method. The
 :attr:`~Mock.mock_calls` attribute records all calls
 to child attributes of the mock - and also to their children.
 .. doctest::
     >>> mock = MagicMock()
     >>> mock.method()
     <MagicMock name='mock.method()' id='...'>
     >>> mock.attribute.method(10, x=53)
     <MagicMock name='mock.attribute.method()' id='...'>
     >>> mock.mock_calls
     [call.method(), call.attribute.method(10, x=53)]
 If you make an assertion about `mock_calls` and any unexpected methods
 have been called, then the assertion will fail. This is useful because as well
 as asserting that the calls you expected have been made, you are also checking
 that they were made in the right order and with no additional calls:
 You use the :data:`call` object to construct lists for comparing with
 `mock_calls`:
 .. doctest::
     >>> expected = [call.method(), call.attribute.method(10, x=53)]
     >>> mock.mock_calls == expected
     True
 Setting Return Values and Attributes
 ------------------------------------
 Setting the return values on a mock object is trivially easy:
 .. doctest::
     >>> mock = Mock()
     >>> mock.return_value = 3
     >>> mock()
 
 Of course you can do the same for methods on the mock:
 .. doctest::
     >>> mock = Mock()
     >>> mock.method.return_value = 3
     >>> mock.method()
 
 The return value can also be set in the constructor:
 .. doctest::
     >>> mock = Mock(return_value=3)
     >>> mock()
 
 If you need an attribute setting on your mock, just do it:
 .. doctest::
     >>> mock = Mock()
     >>> mock.x = 3
     >>> mock.x
 
 Sometimes you want to mock up a more complex situation, like for example
 `mock.connection.cursor().execute("SELECT 1")`. If we wanted this call to
 return a list, then we have to configure the result of the nested call.
 We can use :data:`call` to construct the set of calls in a "chained call" like
 this for easy assertion afterwards:
 .. doctest::
     >>> mock = Mock()
     >>> cursor = mock.connection.cursor.return_value
     >>> cursor.execute.return_value = ['foo']
     >>> mock.connection.cursor().execute("SELECT 1")
     ['foo']
     >>> expected = call.connection.cursor().execute("SELECT 1").call_list()
     >>> mock.mock_calls
     [call.connection.cursor(), call.connection.cursor().execute('SELECT 1')]
     >>> mock.mock_calls == expected
     True
 It is the call to `.call_list()` that turns our call object into a list of
 calls representing the chained calls.
 Raising exceptions with mocks
 -----------------------------
 A useful attribute is :attr:`~Mock.side_effect`. If you set this to an
 exception class or instance then the exception will be raised when the mock
 is called.
 .. doctest::
     >>> mock = Mock(side_effect=Exception('Boom!'))
     >>> mock()
     Traceback (most recent call last):
       ...
     Exception: Boom!
 Side effect functions and iterables
 -----------------------------------
 `side_effect` can also be set to a function or an iterable. The use case for
 `side_effect` as an iterable is where your mock is going to be called several
 times, and you want each call to return a different value. When you set
 `side_effect` to an iterable every call to the mock returns the next value
 from the iterable:
 .. doctest::
     >>> mock = MagicMock(side_effect=[4, 5, 6])
     >>> mock()
 
     >>> mock()
 
     >>> mock()
 
 For more advanced use cases, like dynamically varying the return values
 depending on what the mock is called with, `side_effect` can be a function.
 The function will be called with the same arguments as the mock. Whatever the
 function returns is what the call returns:
 .. doctest::
     >>> vals = {(1, 2): 1, (2, 3): 2}
     >>> def side_effect(*args):
     ...     return vals[args]
     ...
     >>> mock = MagicMock(side_effect=side_effect)
     >>> mock(1, 2)
 
     >>> mock(2, 3)
 
 Creating a Mock from an Existing Object
 ---------------------------------------
 One problem with over use of mocking is that it couples your tests to the
 implementation of your mocks rather than your real code. Suppose you have a
 class that implements `some_method`. In a test for another class, you
 provide a mock of this object that *also* provides `some_method`. If later
 you refactor the first class, so that it no longer has `some_method` - then
 your tests will continue to pass even though your code is now broken!
 `Mock` allows you to provide an object as a specification for the mock,
 using the `spec` keyword argument. Accessing methods / attributes on the
 mock that don't exist on your specification object will immediately raise an
 attribute error. If you change the implementation of your specification, then
 tests that use that class will start failing immediately without you having to
 instantiate the class in those tests.
 .. doctest::
     >>> mock = Mock(spec=SomeClass)
     >>> mock.old_method()
     Traceback (most recent call last):
        ...
     AttributeError: object has no attribute 'old_method'
 If you want a stronger form of specification that prevents the setting
 of arbitrary attributes as well as the getting of them then you can use
 `spec_set` instead of `spec`.
 Patch Decorators
 ================
 .. note::
    With `patch` it matters that you patch objects in the namespace where they
    are looked up. This is normally straightforward, but for a quick guide
    read :ref:`where to patch <where-to-patch>`.
 A common need in tests is to patch a class attribute or a module attribute,
 for example patching a builtin or patching a class in a module to test that it
 is instantiated. Modules and classes are effectively global, so patching on
 them has to be undone after the test or the patch will persist into other
 tests and cause hard to diagnose problems.
 mock provides three convenient decorators for this: `patch`, `patch.object` and
 `patch.dict`. `patch` takes a single string, of the form
 `package.module.Class.attribute` to specify the attribute you are patching. It
 also optionally takes a value that you want the attribute (or class or
 whatever) to be replaced with. 'patch.object' takes an object and the name of
 the attribute you would like patched, plus optionally the value to patch it
 with.
 `patch.object`:
 .. doctest::
     >>> original = SomeClass.attribute
     >>> @patch.object(SomeClass, 'attribute', sentinel.attribute)
     ... def test():
     ...     assert SomeClass.attribute == sentinel.attribute
     ...
     >>> test()
     >>> assert SomeClass.attribute == original
     >>> @patch('package.module.attribute', sentinel.attribute)
     ... def test():
     ...     from package.module import attribute
     ...     assert attribute is sentinel.attribute
     ...
     >>> test()
 If you are patching a module (including `__builtin__`) then use `patch`
 instead of `patch.object`:
 .. doctest::
     >>> mock = MagicMock(return_value = sentinel.file_handle)
     >>> with patch('__builtin__.open', mock):
     ...     handle = open('filename', 'r')
     ...
     >>> mock.assert_called_with('filename', 'r')
     >>> assert handle == sentinel.file_handle, "incorrect file handle returned"
 The module name can be 'dotted', in the form `package.module` if needed:
 .. doctest::
     >>> @patch('package.module.ClassName.attribute', sentinel.attribute)
     ... def test():
     ...     from package.module import ClassName
     ...     assert ClassName.attribute == sentinel.attribute
     ...
     >>> test()
 A nice pattern is to actually decorate test methods themselves:
 .. doctest::
     >>> class MyTest(unittest2.TestCase):
     ...     @patch.object(SomeClass, 'attribute', sentinel.attribute)
     ...     def test_something(self):
     ...         self.assertEqual(SomeClass.attribute, sentinel.attribute)
     ...
     >>> original = SomeClass.attribute
     >>> MyTest('test_something').test_something()
     >>> assert SomeClass.attribute == original
 If you want to patch with a Mock, you can use `patch` with only one argument
 (or `patch.object` with two arguments). The mock will be created for you and
 passed into the test function / method:
 .. doctest::
     >>> class MyTest(unittest2.TestCase):
     ...     @patch.object(SomeClass, 'static_method')
     ...     def test_something(self, mock_method):
     ...         SomeClass.static_method()
     ...         mock_method.assert_called_with()
     ...
     >>> MyTest('test_something').test_something()
 You can stack up multiple patch decorators using this pattern:
 .. doctest::
     >>> class MyTest(unittest2.TestCase):
     ...     @patch('package.module.ClassName1')
     ...     @patch('package.module.ClassName2')
     ...     def test_something(self, MockClass2, MockClass1):
     ...         self.assertTrue(package.module.ClassName1 is MockClass1)
     ...         self.assertTrue(package.module.ClassName2 is MockClass2)
     ...
     >>> MyTest('test_something').test_something()
 When you nest patch decorators the mocks are passed in to the decorated
 function in the same order they applied (the normal *python* order that
 decorators are applied). This means from the bottom up, so in the example
 above the mock for `test_module.ClassName2` is passed in first.
 There is also :func:`patch.dict` for setting values in a dictionary just
 during a scope and restoring the dictionary to its original state when the test
 ends:
 .. doctest::
    >>> foo = {'key': 'value'}
    >>> original = foo.copy()
    >>> with patch.dict(foo, {'newkey': 'newvalue'}, clear=True):
    ...     assert foo == {'newkey': 'newvalue'}
    ...
    >>> assert foo == original
 `patch`, `patch.object` and `patch.dict` can all be used as context managers.
 Where you use `patch` to create a mock for you, you can get a reference to the
 mock using the "as" form of the with statement:
 .. doctest::
     >>> class ProductionClass(object):
     ...     def method(self):
     ...         pass
     ...
     >>> with patch.object(ProductionClass, 'method') as mock_method:
     ...     mock_method.return_value = None
     ...     real = ProductionClass()
     ...     real.method(1, 2, 3)
     ...
     >>> mock_method.assert_called_with(1, 2, 3)
 As an alternative `patch`, `patch.object` and `patch.dict` can be used as
 class decorators. When used in this way it is the same as applying the
 decorator indvidually to every method whose name starts with "test".
 For some more advanced examples, see the :ref:`further-examples` page.

The Tor Browser / annotate

python/mock-1.0.0/docs/getting-started.txt@b8a032363ba2 (annotated)

python/mock-1.0.0/docs/getting-started.txt