unittest.mock
— 入门¶
在 3.3 版本加入。
使用 Mock¶
Mock 修补方法¶
Mock
对象的常见用途包括:
修补方法
记录对象上的方法调用
你可能希望替换对象上的方法,以检查系统其他部分是否使用正确的参数调用了它。
>>> real = SomeClass()
>>> real.method = MagicMock(name='method')
>>> real.method(3, 4, 5, key='value')
<MagicMock name='method()' id='...'>
一旦我们的 mock 被使用(本例中为 real.method
),它就拥有允许你断言其使用方式的方法和属性。
一旦 mock 被调用,其 called
属性将设置为 True
。更重要的是,我们可以使用 assert_called_with()
或 assert_called_once_with()
方法来检查它是否以正确的参数被调用。
此示例测试调用 ProductionClass().method
是否会导致调用 something
方法。
>>> class ProductionClass:
... 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 对象上的方法调用¶
在上一个示例中,我们直接修补了对象上的方法以检查它是否被正确调用。另一个常见用例是将对象传递给方法(或被测系统的某个部分),然后检查它是否以正确的方式被使用。
下面简单的 ProductionClass
有一个 closer
方法。如果它被一个对象调用,那么它会调用该对象上的 close
方法。
>>> class ProductionClass:
... def closer(self, something):
... something.close()
...
因此,为了测试它,我们需要传入一个具有 close
方法的对象,并检查它是否被正确调用。
>>> real = ProductionClass()
>>> mock = Mock()
>>> real.closer(mock)
>>> mock.close.assert_called_with()
我们无需为 mock 提供“close”方法。访问 close 会创建它。因此,如果“close”尚未被调用,那么在测试中访问它将创建它,但 assert_called_with()
将引发失败异常。
Mock 类¶
一个常见的用例是模拟被测代码实例化的类。当你修补一个类时,该类会被一个 mock 替换。实例通过 *调用该类* 来创建。这意味着你可以通过查看被模拟类的返回值来访问“模拟实例”。
在下面的示例中,我们有一个函数 some_function
,它实例化 Foo
并调用其上的一个方法。对 patch()
的调用将类 Foo
替换为一个 mock。这个 Foo
实例是调用 mock 的结果,因此通过修改 mock 的 return_value
来配置它。
>>> 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'
命名你的 mock¶
给你的 mock 命名很有用。名称会显示在 mock 的 repr 中,当 mock 出现在测试失败消息中时会很有帮助。名称也会传播到 mock 的属性或方法中。
>>> mock = MagicMock(name='foo')
>>> mock
<MagicMock name='foo' id='...'>
>>> mock.method
<MagicMock name='foo.method' id='...'>
跟踪所有调用¶
通常你希望跟踪对一个方法的多次调用。mock_calls
属性记录了对 mock 的所有子属性的调用——以及它们的子属性。
>>> 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)]
如果你对 mock_calls
进行断言,并且调用了任何意外的方法,那么断言将失败。这很有用,因为除了断言你期望的调用已经发生之外,你还在检查它们是否以正确的顺序发生并且没有额外的调用。
你使用 call
对象来构建列表,以便与 mock_calls
进行比较。
>>> expected = [call.method(), call.attribute.method(10, x=53)]
>>> mock.mock_calls == expected
True
但是,返回 mock 的调用的参数不会被记录,这意味着无法跟踪祖先创建时使用的参数很重要的嵌套调用。
>>> m = Mock()
>>> m.factory(important=True).deliver()
<Mock name='mock.factory().deliver()' id='...'>
>>> m.mock_calls[-1] == call.factory(important=False).deliver()
True
设置返回值和属性¶
设置 mock 对象的返回值非常容易。
>>> mock = Mock()
>>> mock.return_value = 3
>>> mock()
3
当然,你也可以对 mock 上的方法进行相同的操作。
>>> mock = Mock()
>>> mock.method.return_value = 3
>>> mock.method()
3
返回值也可以在构造函数中设置。
>>> mock = Mock(return_value=3)
>>> mock()
3
如果你的 mock 需要设置属性,直接设置即可。
>>> mock = Mock()
>>> mock.x = 3
>>> mock.x
3
有时你希望模拟更复杂的情况,例如 mock.connection.cursor().execute("SELECT 1")
。如果希望此调用返回一个列表,则必须配置嵌套调用的结果。
我们可以使用 call
来构建这种“链式调用”的调用集合,以便之后轻松断言。
>>> 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
正是对 .call_list()
的调用将我们的调用对象转换为表示链式调用的调用列表。
使用 mock 引发异常¶
一个有用的属性是 side_effect
。如果你将其设置为异常类或实例,那么当 mock 被调用时,该异常将被引发。
>>> mock = Mock(side_effect=Exception('Boom!'))
>>> mock()
Traceback (most recent call last):
...
Exception: Boom!
副作用函数和可迭代对象¶
side_effect
也可以设置为函数或可迭代对象。side_effect
作为可迭代对象的用例是当你的 mock 将被多次调用时,并且你希望每次调用都返回不同的值。当你将 side_effect
设置为可迭代对象时,每次调用 mock 都会从可迭代对象中返回下一个值。
>>> mock = MagicMock(side_effect=[4, 5, 6])
>>> mock()
4
>>> mock()
5
>>> mock()
6
对于更高级的用例,例如根据 mock 被调用的参数动态改变返回值,side_effect
可以是一个函数。该函数将以与 mock 相同的参数被调用。函数返回的任何值都将是调用的返回值。
>>> vals = {(1, 2): 1, (2, 3): 2}
>>> def side_effect(*args):
... return vals[args]
...
>>> mock = MagicMock(side_effect=side_effect)
>>> mock(1, 2)
1
>>> mock(2, 3)
2
模拟异步迭代器¶
从 Python 3.8 开始,AsyncMock
和 MagicMock
支持通过 __aiter__
模拟异步迭代器。__aiter__
的 return_value
属性可用于设置迭代的返回值。
>>> mock = MagicMock() # AsyncMock also works here
>>> mock.__aiter__.return_value = [1, 2, 3]
>>> async def main():
... return [i async for i in mock]
...
>>> asyncio.run(main())
[1, 2, 3]
模拟异步上下文管理器¶
从 Python 3.8 开始,AsyncMock
和 MagicMock
支持通过 __aenter__
和 __aexit__
模拟异步上下文管理器。默认情况下,__aenter__
和 __aexit__
都是返回异步函数的 AsyncMock
实例。
>>> class AsyncContextManager:
... async def __aenter__(self):
... return self
... async def __aexit__(self, exc_type, exc, tb):
... pass
...
>>> mock_instance = MagicMock(AsyncContextManager()) # AsyncMock also works here
>>> async def main():
... async with mock_instance as result:
... pass
...
>>> asyncio.run(main())
>>> mock_instance.__aenter__.assert_awaited_once()
>>> mock_instance.__aexit__.assert_awaited_once()
从现有对象创建 Mock¶
过度使用模拟的一个问题是它将你的测试与模拟的实现而非你的真实代码耦合起来。假设你有一个实现了 some_method
的类。在另一个类的测试中,你提供了一个模拟此对象的 mock,该 mock *也* 提供了 some_method
。如果之后你重构第一个类,使其不再具有 some_method
- 那么你的测试将继续通过,即使你的代码现在已经损坏!
Mock
允许你使用 *spec* 关键字参数提供一个对象作为 mock 的规范。访问 mock 上不存在于你的规范对象上的方法/属性将立即引发属性错误。如果你更改规范的实现,那么使用该类的测试将立即开始失败,而无需你在这些测试中实例化该类。
>>> mock = Mock(spec=SomeClass)
>>> mock.old_method()
Traceback (most recent call last):
...
AttributeError: Mock object has no attribute 'old_method'. Did you mean: 'class_method'?
使用规范还能够对 mock 进行更智能的调用匹配,无论某些参数是作为位置参数还是命名参数传递。
>>> def f(a, b, c): pass
...
>>> mock = Mock(spec=f)
>>> mock(1, 2, 3)
<Mock name='mock()' id='140161580456576'>
>>> mock.assert_called_with(a=1, b=2, c=3)
如果你希望这种更智能的匹配也适用于 mock 上的方法调用,你可以使用自动规范化。
如果你想要一种更强的规范形式,它既可以阻止设置任意属性,也可以阻止获取这些属性,那么你可以使用 *spec_set* 而不是 *spec*。
使用 side_effect 返回每个文件内容¶
mock_open()
用于修补 open()
方法。side_effect
可用于每次调用返回一个新的 Mock 对象。这可用于返回存储在字典中每个文件的不同内容。
DEFAULT = "default"
data_dict = {"file1": "data1",
"file2": "data2"}
def open_side_effect(name):
return mock_open(read_data=data_dict.get(name, DEFAULT))()
with patch("builtins.open", side_effect=open_side_effect):
with open("file1") as file1:
assert file1.read() == "data1"
with open("file2") as file2:
assert file2.read() == "data2"
with open("file3") as file2:
assert file2.read() == "default"
修补装饰器¶
测试中的常见需求是修补类属性或模块属性,例如修补内置函数或修补模块中的类以测试其是否被实例化。模块和类实际上是全局的,因此修补它们后必须在测试后撤销,否则修补将持续到其他测试中并导致难以诊断的问题。
mock 提供了三个方便的装饰器:patch()
、patch.object()
和 patch.dict()
。patch
接受一个字符串,形式为 package.module.Class.attribute
,以指定要修补的属性。它还可以选择接受一个值,你希望用该值替换该属性(或类或任何其他内容)。‘patch.object’ 接受一个对象和要修补的属性名称,以及可选的用于修补的值。
patch.object
:
>>> 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()
如果你正在修补模块(包括 builtins
),那么请使用 patch()
而不是 patch.object()
。
>>> mock = MagicMock(return_value=sentinel.file_handle)
>>> with patch('builtins.open', mock):
... handle = open('filename', 'r')
...
>>> mock.assert_called_with('filename', 'r')
>>> assert handle == sentinel.file_handle, "incorrect file handle returned"
模块名称可以是“点分”形式,如果需要,可以使用 package.module
。
>>> @patch('package.module.ClassName.attribute', sentinel.attribute)
... def test():
... from package.module import ClassName
... assert ClassName.attribute == sentinel.attribute
...
>>> test()
一个很好的模式是实际装饰测试方法本身。
>>> class MyTest(unittest.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
如果你想用 Mock 进行修补,你可以只用一个参数(或 patch.object()
和两个参数)使用 patch()
。Mock 将为你创建并传递给测试函数/方法。
>>> class MyTest(unittest.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()
你可以使用这种模式堆叠多个 patch 装饰器。
>>> class MyTest(unittest.TestCase):
... @patch('package.module.ClassName1')
... @patch('package.module.ClassName2')
... def test_something(self, MockClass2, MockClass1):
... self.assertIs(package.module.ClassName1, MockClass1)
... self.assertIs(package.module.ClassName2, MockClass2)
...
>>> MyTest('test_something').test_something()
当你嵌套 patch 装饰器时,mock 会按照它们应用的顺序(Python 应用装饰器的正常顺序)传递到被装饰的函数中。这意味着从下到上,所以在上面的示例中,test_module.ClassName2
的 mock 会首先传入。
还有 patch.dict()
,用于在某个作用域内设置字典中的值,并在测试结束时将字典恢复到其原始状态。
>>> foo = {'key': 'value'}
>>> original = foo.copy()
>>> with patch.dict(foo, {'newkey': 'newvalue'}, clear=True):
... assert foo == {'newkey': 'newvalue'}
...
>>> assert foo == original
patch
、patch.object
和 patch.dict
都可以用作上下文管理器。
在你使用 patch()
为你创建 mock 的地方,你可以使用 with 语句的“as”形式获取对 mock 的引用。
>>> class ProductionClass:
... 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)
作为替代方案,patch
、patch.object
和 patch.dict
可以用作类装饰器。以这种方式使用时,它与将装饰器单独应用于每个名称以“test”开头的方法相同。
更多示例¶
这里有一些更高级场景的示例。
模拟链式调用¶
一旦你理解了 return_value
属性,使用 mock 模拟链式调用实际上很简单。当 mock 第一次被调用,或者你在它被调用之前获取它的 return_value
时,会创建一个新的 Mock
。
这意味着你可以通过查询 return_value
mock 来查看从模拟对象调用返回的对象是如何被使用的。
>>> mock = Mock()
>>> mock().foo(a=2, b=3)
<Mock name='mock().foo()' id='...'>
>>> mock.return_value.foo.assert_called_with(a=2, b=3)
从这里开始,配置和断言链式调用就简单了。当然,另一种选择是从一开始就以更可测试的方式编写代码……
那么,假设我们有一些代码看起来像这样:
>>> class Something:
... def __init__(self):
... self.backend = BackendProvider()
... def method(self):
... response = self.backend.get_endpoint('foobar').create_call('spam', 'eggs').start_call()
... # more code
假设 BackendProvider
已经经过充分测试,我们如何测试 method()
?具体来说,我们想测试代码段 # more code
是否以正确的方式使用了响应对象。
由于这个调用链是由一个实例属性组成的,我们可以对 Something
实例上的 backend
属性进行猴子补丁。在这种特殊情况下,我们只对最后一次调用 start_call
的返回值感兴趣,因此我们没有太多配置要做。假设它返回的对象是“文件类”的,所以我们将确保我们的响应对象使用内置的 open()
作为其 spec
。
为此,我们创建一个 mock 实例作为我们的 mock 后端,并为其创建一个 mock 响应对象。为了将响应设置为最后一次 start_call
的返回值,我们可以这样做:
mock_backend.get_endpoint.return_value.create_call.return_value.start_call.return_value = mock_response
我们可以使用 configure_mock()
方法以更简洁的方式直接为我们设置返回值。
>>> something = Something()
>>> mock_response = Mock(spec=open)
>>> mock_backend = Mock()
>>> config = {'get_endpoint.return_value.create_call.return_value.start_call.return_value': mock_response}
>>> mock_backend.configure_mock(**config)
有了这些,我们就可以将“模拟后端”打上补丁,并进行实际调用。
>>> something.backend = mock_backend
>>> something.method()
使用 mock_calls
我们可以用一个断言来检查链式调用。链式调用是一行代码中的多个调用,因此 mock_calls
中会有多个条目。我们可以使用 call.call_list()
为我们创建这个调用列表。
>>> chained = call.get_endpoint('foobar').create_call('spam', 'eggs').start_call()
>>> call_list = chained.call_list()
>>> assert mock_backend.mock_calls == call_list
部分模拟¶
在某些测试中,我希望模拟对 datetime.date.today()
的调用以返回已知日期,但我不想阻止被测代码创建新的日期对象。不幸的是,datetime.date
是用 C 编写的,因此我无法直接通过猴子补丁替换静态的 datetime.date.today()
方法。
我发现了一种简单的方法,它实际上是用 mock 包装日期类,但将构造函数的调用传递给真实类(并返回真实实例)。
这里使用 patch decorator
来模拟被测模块中的 date
类。然后将 mock date 类的 side_effect
属性设置为返回真实日期的 lambda 函数。当调用 mock date 类时,side_effect
将构造并返回一个真实日期。
>>> from datetime import date
>>> with patch('mymodule.date') as mock_date:
... mock_date.today.return_value = date(2010, 10, 8)
... mock_date.side_effect = lambda *args, **kw: date(*args, **kw)
...
... assert mymodule.date.today() == date(2010, 10, 8)
... assert mymodule.date(2009, 6, 8) == date(2009, 6, 8)
请注意,我们不是全局修补 datetime.date
,而是修补 *使用* 它的模块中的 date
。请参阅在哪里修补。
当调用 date.today()
时,会返回一个已知日期,但对 date(...)
构造函数的调用仍然返回正常日期。如果没有这个,你可能会发现自己不得不使用与被测代码完全相同的算法来计算预期结果,这是一种经典的测试反模式。
对 date 构造函数的调用记录在 mock_date
属性中(call_count
等),这对于你的测试也可能有用。
在这篇博客文章中讨论了处理模拟日期或其他内置类的另一种方法。
模拟生成器方法¶
Python 生成器是一个使用 yield
语句在迭代时返回一系列值的函数或方法[1]。
调用生成器方法/函数以返回生成器对象。然后迭代该生成器对象。迭代的协议方法是 __iter__()
,因此我们可以使用 MagicMock
来模拟它。
这是一个带有作为生成器实现的“iter”方法的示例类。
>>> class Foo:
... def iter(self):
... for i in [1, 2, 3]:
... yield i
...
>>> foo = Foo()
>>> list(foo.iter())
[1, 2, 3]
我们如何模拟这个类,特别是它的“iter”方法?
要配置迭代返回的值(隐式地在对 list
的调用中),我们需要配置对 foo.iter()
调用返回的对象。
>>> mock_foo = MagicMock()
>>> mock_foo.iter.return_value = iter([1, 2, 3])
>>> list(mock_foo.iter())
[1, 2, 3]
将相同的补丁应用于每个测试方法¶
如果你想为多个测试方法设置多个补丁,最明显的方法是将补丁装饰器应用于每个方法。这会让人觉得不必要的重复。相反,你可以将 patch()
(以其各种形式)用作类装饰器。这会将补丁应用于类上的所有测试方法。测试方法由名称以 test
开头的方法识别。
>>> @patch('mymodule.SomeClass')
... class MyTest(unittest.TestCase):
...
... def test_one(self, MockSomeClass):
... self.assertIs(mymodule.SomeClass, MockSomeClass)
...
... def test_two(self, MockSomeClass):
... self.assertIs(mymodule.SomeClass, MockSomeClass)
...
... def not_a_test(self):
... return 'something'
...
>>> MyTest('test_one').test_one()
>>> MyTest('test_two').test_two()
>>> MyTest('test_two').not_a_test()
'something'
管理补丁的另一种方法是使用补丁方法:start 和 stop。这些方法允许你将补丁移动到你的 setUp
和 tearDown
方法中。
>>> class MyTest(unittest.TestCase):
... def setUp(self):
... self.patcher = patch('mymodule.foo')
... self.mock_foo = self.patcher.start()
...
... def test_foo(self):
... self.assertIs(mymodule.foo, self.mock_foo)
...
... def tearDown(self):
... self.patcher.stop()
...
>>> MyTest('test_foo').run()
如果你使用此技术,则必须通过调用 stop
来确保补丁“撤销”。这可能比你想象的更麻烦,因为如果在 setUp 中引发异常,则不会调用 tearDown。unittest.TestCase.addCleanup()
使这更容易。
>>> class MyTest(unittest.TestCase):
... def setUp(self):
... patcher = patch('mymodule.foo')
... self.addCleanup(patcher.stop)
... self.mock_foo = patcher.start()
...
... def test_foo(self):
... self.assertIs(mymodule.foo, self.mock_foo)
...
>>> MyTest('test_foo').run()
模拟非绑定方法¶
在编写测试时,我需要修补一个 *非绑定方法*(修补类上的方法而不是实例上的方法)。我需要将 self 作为第一个参数传入,因为我想断言哪些对象正在调用这个特定方法。问题是不能用 mock 来修补,因为如果用 mock 替换一个非绑定方法,它在从实例中获取时不会成为绑定方法,因此不会传入 self。解决方法是用一个真实的函数来修补非绑定方法。patch()
装饰器使得用 mock 修补方法变得如此简单,以至于不得不创建一个真实的函数变得很麻烦。
如果你将 autospec=True
传递给 patch,它会用一个 *真实* 的函数对象进行修补。这个函数对象具有与它替换的函数相同的签名,但在底层委托给一个 mock。你仍然可以像以前一样自动创建 mock。这意味着,如果你用它来修补类上的一个非绑定方法,那么如果从实例中获取,模拟函数将被转换为绑定方法。它将传入 self
作为第一个参数,这正是我想要的。
>>> class Foo:
... def foo(self):
... pass
...
>>> with patch.object(Foo, 'foo', autospec=True) as mock_foo:
... mock_foo.return_value = 'foo'
... foo = Foo()
... foo.foo()
...
'foo'
>>> mock_foo.assert_called_once_with(foo)
如果我们不使用 autospec=True
,则非绑定方法会被一个 Mock 实例替换,并且不会以 self
调用。
使用 mock 检查多次调用¶
mock 提供了一个很好的 API,用于对 mock 对象的使用方式进行断言。
>>> mock = Mock()
>>> mock.foo_bar.return_value = None
>>> mock.foo_bar('baz', spam='eggs')
>>> mock.foo_bar.assert_called_with('baz', spam='eggs')
如果你的 mock 只被调用一次,你可以使用 assert_called_once_with()
方法,该方法还会断言 call_count
为一。
>>> mock.foo_bar.assert_called_once_with('baz', spam='eggs')
>>> mock.foo_bar()
>>> mock.foo_bar.assert_called_once_with('baz', spam='eggs')
Traceback (most recent call last):
...
AssertionError: Expected 'foo_bar' to be called once. Called 2 times.
Calls: [call('baz', spam='eggs'), call()].
assert_called_with
和 assert_called_once_with
都对 *最近一次* 调用进行断言。如果你的 mock 将被多次调用,并且你希望对 *所有* 这些调用进行断言,你可以使用 call_args_list
。
>>> mock = Mock(return_value=None)
>>> mock(1, 2, 3)
>>> mock(4, 5, 6)
>>> mock()
>>> mock.call_args_list
[call(1, 2, 3), call(4, 5, 6), call()]
call
助手使得对这些调用进行断言变得容易。你可以构建一个预期的调用列表并将其与 call_args_list
进行比较。这看起来与 call_args_list
的 repr remarkably 相似。
>>> expected = [call(1, 2, 3), call(4, 5, 6), call()]
>>> mock.call_args_list == expected
True
应对可变参数¶
另一种情况很少见,但可能让你感到困扰,那就是当你的 mock 被可变参数调用时。call_args
和 call_args_list
存储参数的 *引用*。如果参数被被测代码修改,那么你将无法再断言 mock 被调用时的值。
这里有一些示例代码展示了这个问题。想象一下在“mymodule”中定义的以下函数:
def frob(val):
pass
def grob(val):
"First frob and then clear val"
frob(val)
val.clear()
当我们尝试测试 grob
是否使用正确的参数调用 frob
时,看会发生什么:
>>> with patch('mymodule.frob') as mock_frob:
... val = {6}
... mymodule.grob(val)
...
>>> val
set()
>>> mock_frob.assert_called_with({6})
Traceback (most recent call last):
...
AssertionError: Expected: (({6},), {})
Called with: ((set(),), {})
一种可能性是 mock 复制你传入的参数。但这可能会导致你进行依赖对象标识来判断相等的断言时出现问题。
这里有一个解决方案,它使用 side_effect
功能。如果你为 mock 提供一个 side_effect
函数,那么 side_effect
将以与 mock 相同的参数被调用。这给了我们一个机会来复制参数并存储它们以供后续断言使用。在这个示例中,我使用 *另一个* mock 来存储参数,以便我可以使用 mock 方法进行断言。一个辅助函数再次为我设置了这些。
>>> from copy import deepcopy
>>> from unittest.mock import Mock, patch, DEFAULT
>>> def copy_call_args(mock):
... new_mock = Mock()
... def side_effect(*args, **kwargs):
... args = deepcopy(args)
... kwargs = deepcopy(kwargs)
... new_mock(*args, **kwargs)
... return DEFAULT
... mock.side_effect = side_effect
... return new_mock
...
>>> with patch('mymodule.frob') as mock_frob:
... new_mock = copy_call_args(mock_frob)
... val = {6}
... mymodule.grob(val)
...
>>> new_mock.assert_called_with({6})
>>> new_mock.call_args
call({6})
调用 copy_call_args
时传入将被调用的 mock。它返回一个新的 mock,我们将在其上进行断言。side_effect
函数会复制参数并用复制的参数调用我们的 new_mock
。
备注
如果你的 mock 只会被使用一次,有一种更简单的方法可以在调用时检查参数。你只需在 side_effect
函数中进行检查即可。
>>> def side_effect(arg):
... assert arg == {6}
...
>>> mock = Mock(side_effect=side_effect)
>>> mock({6})
>>> mock(set())
Traceback (most recent call last):
...
AssertionError
另一种方法是创建 Mock
或 MagicMock
的子类,它会复制(使用 copy.deepcopy()
)参数。这是一个示例实现:
>>> from copy import deepcopy
>>> class CopyingMock(MagicMock):
... def __call__(self, /, *args, **kwargs):
... args = deepcopy(args)
... kwargs = deepcopy(kwargs)
... return super().__call__(*args, **kwargs)
...
>>> c = CopyingMock(return_value=None)
>>> arg = set()
>>> c(arg)
>>> arg.add(1)
>>> c.assert_called_with(set())
>>> c.assert_called_with(arg)
Traceback (most recent call last):
...
AssertionError: expected call not found.
Expected: mock({1})
Actual: mock(set())
>>> c.foo
<CopyingMock name='mock.foo' id='...'>
当你子类化 Mock
或 MagicMock
时,所有动态创建的属性和 return_value
都将自动使用你的子类。这意味着 CopyingMock
的所有子项也将具有 CopyingMock
类型。
嵌套补丁¶
使用 patch 作为上下文管理器很不错,但是如果你进行多次 patch,你可能会遇到嵌套的 with 语句,导致缩进越来越深。
>>> class MyTest(unittest.TestCase):
...
... def test_foo(self):
... with patch('mymodule.Foo') as mock_foo:
... with patch('mymodule.Bar') as mock_bar:
... with patch('mymodule.Spam') as mock_spam:
... assert mymodule.Foo is mock_foo
... assert mymodule.Bar is mock_bar
... assert mymodule.Spam is mock_spam
...
>>> original = mymodule.Foo
>>> MyTest('test_foo').test_foo()
>>> assert mymodule.Foo is original
通过 unittest cleanup
函数和 patch 方法:start 和 stop,我们可以在没有嵌套缩进的情况下实现相同的效果。一个简单的辅助方法 create_patch
会放置补丁并为我们返回创建的 mock。
>>> class MyTest(unittest.TestCase):
...
... def create_patch(self, name):
... patcher = patch(name)
... thing = patcher.start()
... self.addCleanup(patcher.stop)
... return thing
...
... def test_foo(self):
... mock_foo = self.create_patch('mymodule.Foo')
... mock_bar = self.create_patch('mymodule.Bar')
... mock_spam = self.create_patch('mymodule.Spam')
...
... assert mymodule.Foo is mock_foo
... assert mymodule.Bar is mock_bar
... assert mymodule.Spam is mock_spam
...
>>> original = mymodule.Foo
>>> MyTest('test_foo').run()
>>> assert mymodule.Foo is original
使用 MagicMock 模拟字典¶
你可能希望模拟字典或其他容器对象,记录对其的所有访问,同时让它仍然像字典一样运行。
我们可以使用 MagicMock
来实现这一点,它将像字典一样运行,并使用 side_effect
将字典访问委托给一个受我们控制的真实底层字典。
当我们的 MagicMock
的 __getitem__()
和 __setitem__()
方法被调用时(正常的字典访问),side_effect
将与键(以及在 __setitem__
的情况下,也包括值)一起被调用。我们还可以控制返回的内容。
使用 MagicMock
后,我们可以使用 call_args_list
等属性来断言字典的使用方式。
>>> my_dict = {'a': 1, 'b': 2, 'c': 3}
>>> def getitem(name):
... return my_dict[name]
...
>>> def setitem(name, val):
... my_dict[name] = val
...
>>> mock = MagicMock()
>>> mock.__getitem__.side_effect = getitem
>>> mock.__setitem__.side_effect = setitem
备注
使用 MagicMock
的替代方法是使用 Mock
,并且 *只* 提供你特别想要的魔术方法。
>>> mock = Mock()
>>> mock.__getitem__ = Mock(side_effect=getitem)
>>> mock.__setitem__ = Mock(side_effect=setitem)
第三种选择是使用 MagicMock
,但传入 dict
作为 *spec*(或 *spec_set*)参数,这样创建的 MagicMock
只具有字典魔术方法。
>>> mock = MagicMock(spec_set=dict)
>>> mock.__getitem__.side_effect = getitem
>>> mock.__setitem__.side_effect = setitem
有了这些副作用函数,mock
将像普通字典一样运行,但会记录访问。如果你尝试访问不存在的键,它甚至会引发 KeyError
。
>>> mock['a']
1
>>> mock['c']
3
>>> mock['d']
Traceback (most recent call last):
...
KeyError: 'd'
>>> mock['b'] = 'fish'
>>> mock['d'] = 'eggs'
>>> mock['b']
'fish'
>>> mock['d']
'eggs'
使用后,你可以使用正常的 mock 方法和属性对访问进行断言。
>>> mock.__getitem__.call_args_list
[call('a'), call('c'), call('d'), call('b'), call('d')]
>>> mock.__setitem__.call_args_list
[call('b', 'fish'), call('d', 'eggs')]
>>> my_dict
{'a': 1, 'b': 'fish', 'c': 3, 'd': 'eggs'}
Mock 子类及其属性¶
你可能希望子类化 Mock
的原因有很多。一个原因可能是添加辅助方法。这是一个愚蠢的示例:
>>> class MyMock(MagicMock):
... def has_been_called(self):
... return self.called
...
>>> mymock = MyMock(return_value=None)
>>> mymock
<MyMock id='...'>
>>> mymock.has_been_called()
False
>>> mymock()
>>> mymock.has_been_called()
True
Mock
实例的标准行为是属性和返回值 mock 的类型与其所访问的 mock 的类型相同。这确保 Mock
属性是 Mocks
,MagicMock
属性是 MagicMocks
[2]。因此,如果你通过子类化来添加辅助方法,那么它们也将在你的子类实例的属性和返回值 mock 上可用。
>>> mymock.foo
<MyMock name='mock.foo' id='...'>
>>> mymock.foo.has_been_called()
False
>>> mymock.foo()
<MyMock name='mock.foo()' id='...'>
>>> mymock.foo.has_been_called()
True
有时这很不方便。例如,一位用户正在子类化 mock 以创建 Twisted 适配器。将此应用于属性实际上会导致错误。
Mock
(以各种形式)使用一个名为 _get_child_mock
的方法来为属性和返回值创建这些“子 mock”。你可以通过覆盖此方法来阻止你的子类用于属性。它的签名是它接受任意关键字参数(**kwargs
),然后这些参数会传递给 mock 构造函数。
>>> class Subclass(MagicMock):
... def _get_child_mock(self, /, **kwargs):
... return MagicMock(**kwargs)
...
>>> mymock = Subclass()
>>> mymock.foo
<MagicMock name='mock.foo' id='...'>
>>> assert isinstance(mymock, Subclass)
>>> assert not isinstance(mymock.foo, Subclass)
>>> assert not isinstance(mymock(), Subclass)
此规则的例外是非可调用 mock。属性使用可调用变体,否则非可调用 mock 将无法拥有可调用方法。
使用 patch.dict 模拟导入¶
在某些情况下,模拟可能会很困难,即函数内部有局部导入。这些更难模拟,因为它们没有使用我们可以修补的模块命名空间中的对象。
一般来说,应该避免局部导入。它们有时是为了防止循环依赖而做的,对此 *通常* 有更好的方法来解决问题(重构代码),或者通过延迟导入来防止“前期成本”。这也可以通过比无条件的局部导入更好的方法解决(将模块存储为类或模块属性,并且只在第一次使用时导入)。
抛开这些,有一种方法可以使用 mock
来影响导入的结果。导入会从 sys.modules
字典中获取一个 *对象*。请注意,它获取的是一个 *对象*,该对象不必是模块。第一次导入模块会导致一个模块对象被放入 sys.modules
中,所以通常当你导入某些东西时,你会得到一个模块。然而,情况并非总是如此。
这意味着你可以使用 patch.dict()
来 *暂时* 在 sys.modules
中放置一个 mock。在此补丁激活期间的任何导入都将获取该 mock。当补丁完成时(装饰函数退出,with 语句体完成或调用 patcher.stop()
),之前存在的任何内容都将安全恢复。
这是一个模拟“fooble”模块的示例。
>>> import sys
>>> mock = Mock()
>>> with patch.dict('sys.modules', {'fooble': mock}):
... import fooble
... fooble.blob()
...
<Mock name='mock.blob()' id='...'>
>>> assert 'fooble' not in sys.modules
>>> mock.blob.assert_called_once_with()
正如你所看到的,import fooble
成功了,但是退出后,sys.modules
中没有留下“fooble”。
这也适用于 from module import name
形式。
>>> mock = Mock()
>>> with patch.dict('sys.modules', {'fooble': mock}):
... from fooble import blob
... blob.blip()
...
<Mock name='mock.blob.blip()' id='...'>
>>> mock.blob.blip.assert_called_once_with()
稍加努力,你还可以模拟包导入。
>>> mock = Mock()
>>> modules = {'package': mock, 'package.module': mock.module}
>>> with patch.dict('sys.modules', modules):
... from package.module import fooble
... fooble()
...
<Mock name='mock.module.fooble()' id='...'>
>>> mock.module.fooble.assert_called_once_with()
跟踪调用顺序和更简洁的调用断言¶
Mock
类允许你通过 method_calls
属性跟踪 mock 对象上的方法调用 *顺序*。但是,这不允许你跟踪独立 mock 对象之间的调用顺序,我们可以使用 mock_calls
来实现相同的效果。
因为 mock 会在 mock_calls
中跟踪对子 mock 的调用,并且访问 mock 的任意属性会创建一个子 mock,所以我们可以从父 mock 创建独立的 mock。然后,对这些子 mock 的调用将全部按顺序记录在父 mock 的 mock_calls
中。
>>> manager = Mock()
>>> mock_foo = manager.foo
>>> mock_bar = manager.bar
>>> mock_foo.something()
<Mock name='mock.foo.something()' id='...'>
>>> mock_bar.other.thing()
<Mock name='mock.bar.other.thing()' id='...'>
>>> manager.mock_calls
[call.foo.something(), call.bar.other.thing()]
然后,我们可以通过与管理器 mock 上的 mock_calls
属性进行比较来断言调用,包括顺序。
>>> expected_calls = [call.foo.something(), call.bar.other.thing()]
>>> manager.mock_calls == expected_calls
True
如果 patch
正在创建并放置你的 mock,那么你可以使用 attach_mock()
方法将它们附加到管理器 mock。附加后,调用将记录在管理器的 mock_calls
中。
>>> manager = MagicMock()
>>> with patch('mymodule.Class1') as MockClass1:
... with patch('mymodule.Class2') as MockClass2:
... manager.attach_mock(MockClass1, 'MockClass1')
... manager.attach_mock(MockClass2, 'MockClass2')
... MockClass1().foo()
... MockClass2().bar()
<MagicMock name='mock.MockClass1().foo()' id='...'>
<MagicMock name='mock.MockClass2().bar()' id='...'>
>>> manager.mock_calls
[call.MockClass1(),
call.MockClass1().foo(),
call.MockClass2(),
call.MockClass2().bar()]
如果进行了许多调用,但你只对其中的特定序列感兴趣,那么另一种方法是使用 assert_has_calls()
方法。它接受一个调用列表(使用 call
对象构造)。如果该调用序列在 mock_calls
中,则断言成功。
>>> m = MagicMock()
>>> m().foo().bar().baz()
<MagicMock name='mock().foo().bar().baz()' id='...'>
>>> m.one().two().three()
<MagicMock name='mock.one().two().three()' id='...'>
>>> calls = call.one().two().three().call_list()
>>> m.assert_has_calls(calls)
即使链式调用 m.one().two().three()
不是对 mock 进行的唯一调用,断言仍然成功。
有时一个 mock 可能会被多次调用,而你只对其中 *一些* 调用进行断言。你甚至可能不关心顺序。在这种情况下,你可以将 any_order=True
传递给 assert_has_calls
。
>>> m = MagicMock()
>>> m(1), m.two(2, 3), m.seven(7), m.fifty('50')
(...)
>>> calls = [call.fifty('50'), call(1), call.seven(7)]
>>> m.assert_has_calls(calls, any_order=True)
更复杂的参数匹配¶
使用与 ANY
相同的基本概念,我们可以实现匹配器,以对用作 mock 参数的对象进行更复杂的断言。
假设我们期望某个对象被传递给一个 mock,该对象默认基于对象标识(这是用户定义类的 Python 默认值)进行相等比较。要使用 assert_called_with()
,我们需要传递完全相同的对象。如果我们只对该对象的一些属性感兴趣,那么我们可以创建一个匹配器来为我们检查这些属性。
在此示例中,你可以看到对 assert_called_with
的“标准”调用不足以满足要求。
>>> class Foo:
... def __init__(self, a, b):
... self.a, self.b = a, b
...
>>> mock = Mock(return_value=None)
>>> mock(Foo(1, 2))
>>> mock.assert_called_with(Foo(1, 2))
Traceback (most recent call last):
...
AssertionError: expected call not found.
Expected: mock(<__main__.Foo object at 0x...>)
Actual: mock(<__main__.Foo object at 0x...>)
我们的 Foo
类的比较函数可能如下所示:
>>> def compare(self, other):
... if not type(self) == type(other):
... return False
... if self.a != other.a:
... return False
... if self.b != other.b:
... return False
... return True
...
而一个可以使用这样的比较函数进行相等操作的匹配器对象将如下所示:
>>> class Matcher:
... def __init__(self, compare, some_obj):
... self.compare = compare
... self.some_obj = some_obj
... def __eq__(self, other):
... return self.compare(self.some_obj, other)
...
将所有这些放在一起
>>> match_foo = Matcher(compare, Foo(1, 2))
>>> mock.assert_called_with(match_foo)
Matcher
使用我们的比较函数和我们想要比较的 Foo
对象进行实例化。在 assert_called_with
中,将调用 Matcher
的相等方法,该方法将 mock 被调用时传入的对象与我们创建匹配器时使用的对象进行比较。如果它们匹配,则 assert_called_with
通过,否则会引发 AssertionError
。
>>> match_wrong = Matcher(compare, Foo(3, 4))
>>> mock.assert_called_with(match_wrong)
Traceback (most recent call last):
...
AssertionError: Expected: ((<Matcher object at 0x...>,), {})
Called with: ((<Foo object at 0x...>,), {})
稍作调整,你可以让比较函数直接引发 AssertionError
,并提供更有用的失败消息。
从 1.5 版本开始,Python 测试库 PyHamcrest 以其相等匹配器 (hamcrest.library.integration.match_equality) 的形式提供了类似的功能,这可能在此处有用。