到目前为止，我们的测试已经覆盖了RemovalService， 我们不会对我们测试用例中UploadService的内部函数rm进行验证。相反，我们将调用UploadService的RemovalService.rm方法来进行简单的测试（为了不产生其他副作用），我们通过之前的测试用例可以知道它可以正确地工作。
　　有两种方法可以实现以上需求:
　　1.模拟RemovalService.rm方法本身。
　　2.在UploadService类的构造函数中提供一个模拟实例。
　　因为这两种方法都是单元测试中非常重要的方法，所以我们将同时对这两种方法进行回顾。
　　选项1: 模拟实例的方法
　　该模拟库有一个特殊的方法用来装饰模拟对象实例的方法和参数。@mock.patch.object 进行装饰：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from mymodule import RemovalService， UploadService
import mock
import unittestclass
RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self， mock_os， mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called， "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
@mock.patch.object(RemovalService， 'rm')
def test_upload_complete(self， mock_rm):
# build our dependencies
removal_service = RemovalService()
reference = UploadService(removal_service)
# call upload_complete， which should， in turn， call `rm`:
reference.upload_complete("my uploaded file")
# check that it called the rm method of any RemovalService
mock_rm.assert_called_with("my uploaded file")
# check that it called the rm method of _our_ removal_service
removal_service.rm.assert_called_with("my uploaded file")
　　太棒了！我们验证了上传服务成功调用了实例的rm方法。你是不是注意到这当中有意思的地方了？这种修补机制实际上取代了我们的测试方法的删除服务实例的rm方法。这意味着，我们实际上可以检查该实例本身。如果你想了解更多，可以试着在模拟测试的代码中下断点来更好的认识这种修补机制是如何工作的。
　　陷阱：装饰的顺序
　　当使用多个装饰方法来装饰测试方法的时候，装饰的顺序很重要，但很容易混乱。基本上，当装饰方法呗映射到带参数的测试方法中时，装饰方法的工作顺序是反向的。比如下面这个例子：
@mock.patch('mymodule.sys')
@mock.patch('mymodule.os')
@mock.patch('mymodule.os.path')
def test_something(self， mock_os_path， mock_os， mock_sys):
pass
　　注意到了吗，我们的装饰方法的参数是反向匹配的？ 这是有部分原因是因为Python的工作方式。下面是使用多个装饰方法的时候，实际的代码执行顺序：
　　1
　　patch_sys(patch_os(patch_os_path(test_something)))
　　由于这个关于sys的补丁在外层，因此会在后被执行，使得它成为实际测试方法的后一个参数。请特别注意这一点，并且在做测试使用调试器来保证正确的参数按照正确的顺序被注入。
　　选项2: 创建模拟测试接口
　　我们可以在UploadService的构造函数中提供一个模拟测试实例，而不是模拟创建具体的模拟测试方法。 我推荐使用选项1的方法，因为它更精确，但在多数情况下，选项2是必要的并且更加有效。让我们再次重构我们的测试实例：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from mymodule import RemovalService， UploadService
import mock
import unittestclass
RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self， mock_os， mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called， "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
def test_upload_complete(self， mock_rm):
# build our dependencies
mock_removal_service = mock.create_autospec(RemovalService)
reference = UploadService(mock_removal_service)
# call upload_complete， which should， in turn， call `rm`:
reference.upload_complete("my uploaded file")
# test that it called the rm method
mock_removal_service.rm.assert_called_with("my uploaded file")
　　在这个例子中，我们甚至不需要补充任何功能，只需创建一个带auto-spec方法的RemovalService类，然后将该实例注入到UploadService中对方法验证。
　　mock.create_autospec为类提供了一个同等功能实例。这意味着，实际上来说，在使用返回的实例进行交互的时候，如果使用了非法的方法将会引发异常。更具体地说，如果一个方法被调用时的参数数目不正确，将引发一个异常。这对于重构来说是非常重要。当一个库发生变化的时候，中断测试正是所期望的。如果不使用auto-spec，即使底层的实现已经破坏，我们的测试仍然会通过。
　　陷阱：mock.Mock和mock.MagicMock类
　　mock库包含两个重要的类mock.Mock和mock.MagicMock，大多数内部函数都是建立在这两个类之上的。在选择使用mock.Mock实例，mock.MagicMock实例或auto-spec方法的时候，通常倾向于选择使用 auto-spec方法，因为它能够对未来的变化保持测试的合理性。这是因为mock.Mock和mock.MagicMock会无视底层的API，接受所有的方法调用和参数赋值。比如下面这个用例：
class Target(object):
def apply(value):
return valuedef method(target， value):
return target.apply(value)
　　我们像下面这样使用mock.Mock实例来做测试：
class MethodTestCase(unittest.TestCase):
def test_method(self):
target = mock.Mock()
method(target， "value")
target.apply.assert_called_with("value")
　　这个逻辑看似合理，但如果我们修改Target.apply方法接受更多参数：
class Target(object):
def apply(value， are_you_sure):
if are_you_sure:
return value
else:
return None
　　重新运行你的测试，然后你会发现它仍然能够通过。这是因为它不是针对你的API创建的。这是为什么你总是应该使用create_autospec方法，并且在使用@patch和@patch.object装饰方法时使用autospec参数。
　　真实世界的例子: 模仿一次 Facebook API 调用
　　在结束之际，让我写一个更加实用的真实世界的例子， 这在我们的介绍部分曾今提到过: 向Facebook发送一个消息. 我们会写一个漂亮的封装类，和一个产生回应的测试用例.
import facebookclass
SimpleFacebook(object):
def __init__(self， oauth_token):
self.graph = facebook.GraphAPI(oauth_token)    def post_message(self， message):
"""Posts a message to the Facebook wall."""
self.graph.put_object("me"， "feed"， message=message)
　　下面是我们的测试用例， 它检查到我发送了信息，但并没有实际的发送出这条信息（到Facebook上）:
import facebook
import simple_facebook
import mock
import unittestclass
SimpleFacebookTestCase(unittest.TestCase):
@mock.patch.object(facebook.GraphAPI， 'put_object'， autospec=True)
def test_post_message(self， mock_put_object):
sf = simple_facebook.SimpleFacebook("fake oauth token")
sf.post_message("Hello World!")        # verify
mock_put_object.assert_called_with(message="Hello World!")
　　我们目前所看到的，在Python中用 mock 开始编写更加聪明的测试是真的很简单的.
　　总结
　　Python的 mock 库， 使用起来是有点子迷惑， 是单元测试的游戏规则变革者. 我们通过开始在单元测试中使用 mock ，展示了一些通常的使用场景， 希望这篇文章能帮助 Python 克服一开始的障碍，写出的，能经得起测试的代码.