The Tor Browser / file comparison
comparison: python/mock-1.0.0/PKG-INFO
python/mock-1.0.0/PKG-INFO
- branch
- TOR_BUG_9701
- changeset 14
- 925c144e1f1f
equal
deleted
inserted
replaced
| -1:000000000000 | 0:e3df28c32f14 |
|---|---|
| 1 Metadata-Version: 1.0 | |
| 2 Name: mock | |
| 3 Version: 1.0.0 | |
| 4 Summary: A Python Mocking and Patching Library for Testing | |
| 5 Home-page: http://www.voidspace.org.uk/python/mock/ | |
| 6 Author: Michael Foord | |
| 7 Author-email: michael@voidspace.org.uk | |
| 8 License: UNKNOWN | |
| 9 Description: mock is a library for testing in Python. It allows you to replace parts of | |
| 10 your system under test with mock objects and make assertions about how they | |
| 11 have been used. | |
| 12 | |
| 13 mock is now part of the Python standard library, available as `unittest.mock < | |
| 14 http://docs.python.org/py3k/library/unittest.mock.html#module-unittest.mock>`_ | |
| 15 in Python 3.3 onwards. | |
| 16 | |
| 17 mock provides a core `MagicMock` class removing the need to create a host of | |
| 18 stubs throughout your test suite. After performing an action, you can make | |
| 19 assertions about which methods / attributes were used and arguments they were | |
| 20 called with. You can also specify return values and set needed attributes in | |
| 21 the normal way. | |
| 22 | |
| 23 mock is tested on Python versions 2.4-2.7 and Python 3. mock is also tested | |
| 24 with the latest versions of Jython and pypy. | |
| 25 | |
| 26 The mock module also provides utility functions / objects to assist with | |
| 27 testing, particularly monkey patching. | |
| 28 | |
| 29 * `PDF documentation for 1.0 beta 1 | |
| 30 <http://www.voidspace.org.uk/downloads/mock-1.0.0.pdf>`_ | |
| 31 * `mock on google code (repository and issue tracker) | |
| 32 <http://code.google.com/p/mock/>`_ | |
| 33 * `mock documentation | |
| 34 <http://www.voidspace.org.uk/python/mock/>`_ | |
| 35 * `mock on PyPI <http://pypi.python.org/pypi/mock/>`_ | |
| 36 * `Mailing list (testing-in-python@lists.idyll.org) | |
| 37 <http://lists.idyll.org/listinfo/testing-in-python>`_ | |
| 38 | |
| 39 Mock is very easy to use and is designed for use with | |
| 40 `unittest <http://pypi.python.org/pypi/unittest2>`_. Mock is based on | |
| 41 the 'action -> assertion' pattern instead of 'record -> replay' used by many | |
| 42 mocking frameworks. See the `mock documentation`_ for full details. | |
| 43 | |
| 44 Mock objects create all attributes and methods as you access them and store | |
| 45 details of how they have been used. You can configure them, to specify return | |
| 46 values or limit what attributes are available, and then make assertions about | |
| 47 how they have been used:: | |
| 48 | |
| 49 >>> from mock import Mock | |
| 50 >>> real = ProductionClass() | |
| 51 >>> real.method = Mock(return_value=3) | |
| 52 >>> real.method(3, 4, 5, key='value') | |
| 53 3 | |
| 54 >>> real.method.assert_called_with(3, 4, 5, key='value') | |
| 55 | |
| 56 `side_effect` allows you to perform side effects, return different values or | |
| 57 raise an exception when a mock is called:: | |
| 58 | |
| 59 >>> mock = Mock(side_effect=KeyError('foo')) | |
| 60 >>> mock() | |
| 61 Traceback (most recent call last): | |
| 62 ... | |
| 63 KeyError: 'foo' | |
| 64 >>> values = {'a': 1, 'b': 2, 'c': 3} | |
| 65 >>> def side_effect(arg): | |
| 66 ... return values[arg] | |
| 67 ... | |
| 68 >>> mock.side_effect = side_effect | |
| 69 >>> mock('a'), mock('b'), mock('c') | |
| 70 (3, 2, 1) | |
| 71 >>> mock.side_effect = [5, 4, 3, 2, 1] | |
| 72 >>> mock(), mock(), mock() | |
| 73 (5, 4, 3) | |
| 74 | |
| 75 Mock has many other ways you can configure it and control its behaviour. For | |
| 76 example the `spec` argument configures the mock to take its specification from | |
| 77 another object. Attempting to access attributes or methods on the mock that | |
| 78 don't exist on the spec will fail with an `AttributeError`. | |
| 79 | |
| 80 The `patch` decorator / context manager makes it easy to mock classes or | |
| 81 objects in a module under test. The object you specify will be replaced with a | |
| 82 mock (or other object) during the test and restored when the test ends:: | |
| 83 | |
| 84 >>> from mock import patch | |
| 85 >>> @patch('test_module.ClassName1') | |
| 86 ... @patch('test_module.ClassName2') | |
| 87 ... def test(MockClass2, MockClass1): | |
| 88 ... test_module.ClassName1() | |
| 89 ... test_module.ClassName2() | |
| 90 | |
| 91 ... assert MockClass1.called | |
| 92 ... assert MockClass2.called | |
| 93 ... | |
| 94 >>> test() | |
| 95 | |
| 96 .. note:: | |
| 97 | |
| 98 When you nest patch decorators the mocks are passed in to the decorated | |
| 99 function in the same order they applied (the normal *python* order that | |
| 100 decorators are applied). This means from the bottom up, so in the example | |
| 101 above the mock for `test_module.ClassName2` is passed in first. | |
| 102 | |
| 103 With `patch` it matters that you patch objects in the namespace where they | |
| 104 are looked up. This is normally straightforward, but for a quick guide | |
| 105 read `where to patch | |
| 106 <http://www.voidspace.org.uk/python/mock/patch.html#where-to-patch>`_. | |
| 107 | |
| 108 As well as a decorator `patch` can be used as a context manager in a with | |
| 109 statement:: | |
| 110 | |
| 111 >>> with patch.object(ProductionClass, 'method') as mock_method: | |
| 112 ... mock_method.return_value = None | |
| 113 ... real = ProductionClass() | |
| 114 ... real.method(1, 2, 3) | |
| 115 ... | |
| 116 >>> mock_method.assert_called_once_with(1, 2, 3) | |
| 117 | |
| 118 There is also `patch.dict` for setting values in a dictionary just during the | |
| 119 scope of a test and restoring the dictionary to its original state when the | |
| 120 test ends:: | |
| 121 | |
| 122 >>> foo = {'key': 'value'} | |
| 123 >>> original = foo.copy() | |
| 124 >>> with patch.dict(foo, {'newkey': 'newvalue'}, clear=True): | |
| 125 ... assert foo == {'newkey': 'newvalue'} | |
| 126 ... | |
| 127 >>> assert foo == original | |
| 128 | |
| 129 Mock supports the mocking of Python magic methods. The easiest way of | |
| 130 using magic methods is with the `MagicMock` class. It allows you to do | |
| 131 things like:: | |
| 132 | |
| 133 >>> from mock import MagicMock | |
| 134 >>> mock = MagicMock() | |
| 135 >>> mock.__str__.return_value = 'foobarbaz' | |
| 136 >>> str(mock) | |
| 137 'foobarbaz' | |
| 138 >>> mock.__str__.assert_called_once_with() | |
| 139 | |
| 140 Mock allows you to assign functions (or other Mock instances) to magic methods | |
| 141 and they will be called appropriately. The MagicMock class is just a Mock | |
| 142 variant that has all of the magic methods pre-created for you (well - all the | |
| 143 useful ones anyway). | |
| 144 | |
| 145 The following is an example of using magic methods with the ordinary Mock | |
| 146 class:: | |
| 147 | |
| 148 >>> from mock import Mock | |
| 149 >>> mock = Mock() | |
| 150 >>> mock.__str__ = Mock(return_value = 'wheeeeee') | |
| 151 >>> str(mock) | |
| 152 'wheeeeee' | |
| 153 | |
| 154 For ensuring that the mock objects your tests use have the same api as the | |
| 155 objects they are replacing, you can use "auto-speccing". Auto-speccing can | |
| 156 be done through the `autospec` argument to patch, or the `create_autospec` | |
| 157 function. Auto-speccing creates mock objects that have the same attributes | |
| 158 and methods as the objects they are replacing, and any functions and methods | |
| 159 (including constructors) have the same call signature as the real object. | |
| 160 | |
| 161 This ensures that your mocks will fail in the same way as your production | |
| 162 code if they are used incorrectly:: | |
| 163 | |
| 164 >>> from mock import create_autospec | |
| 165 >>> def function(a, b, c): | |
| 166 ... pass | |
| 167 ... | |
| 168 >>> mock_function = create_autospec(function, return_value='fishy') | |
| 169 >>> mock_function(1, 2, 3) | |
| 170 'fishy' | |
| 171 >>> mock_function.assert_called_once_with(1, 2, 3) | |
| 172 >>> mock_function('wrong arguments') | |
| 173 Traceback (most recent call last): | |
| 174 ... | |
| 175 TypeError: <lambda>() takes exactly 3 arguments (1 given) | |
| 176 | |
| 177 `create_autospec` can also be used on classes, where it copies the signature of | |
| 178 the `__init__` method, and on callable objects where it copies the signature of | |
| 179 the `__call__` method. | |
| 180 | |
| 181 The distribution contains tests and documentation. The tests require | |
| 182 `unittest2 <http://pypi.python.org/pypi/unittest2>`_ to run. | |
| 183 | |
| 184 Docs from the in-development version of `mock` can be found at | |
| 185 `mock.readthedocs.org <http://mock.readthedocs.org>`_. | |
| 186 | |
| 187 Keywords: testing,test,mock,mocking,unittest,patching,stubs,fakes,doubles | |
| 188 Platform: UNKNOWN | |
| 189 Classifier: Development Status :: 5 - Production/Stable | |
| 190 Classifier: Environment :: Console | |
| 191 Classifier: Intended Audience :: Developers | |
| 192 Classifier: License :: OSI Approved :: BSD License | |
| 193 Classifier: Programming Language :: Python | |
| 194 Classifier: Programming Language :: Python :: 2 | |
| 195 Classifier: Programming Language :: Python :: 3 | |
| 196 Classifier: Programming Language :: Python :: 2.4 | |
| 197 Classifier: Programming Language :: Python :: 2.5 | |
| 198 Classifier: Programming Language :: Python :: 2.6 | |
| 199 Classifier: Programming Language :: Python :: 2.7 | |
| 200 Classifier: Programming Language :: Python :: 3.1 | |
| 201 Classifier: Programming Language :: Python :: 3.2 | |
| 202 Classifier: Programming Language :: Python :: Implementation :: CPython | |
| 203 Classifier: Programming Language :: Python :: Implementation :: PyPy | |
| 204 Classifier: Programming Language :: Python :: Implementation :: Jython | |
| 205 Classifier: Operating System :: OS Independent | |
| 206 Classifier: Topic :: Software Development :: Libraries | |
| 207 Classifier: Topic :: Software Development :: Libraries :: Python Modules | |
| 208 Classifier: Topic :: Software Development :: Testing |
