如何不靠耐心测试
通常，我们编写的软件会直接与那些我们称之为“肮脏的”服务交互。通俗地说，服务对我们的应用来说是至关重要的，它们之间的交互是我们设计好的，但这会带来我们不希望的副作用——就是那些在我们自己测试的时候不希望的功能。
比如，可能我们正在写一个社交软件并且想测试一下“发布到Facebook的功能”，但是我们不希望每次运行测试集的时候都发布到Facebook上。
Python的unittest库中有一个子包叫unittest.mock——或者你把它声明成一个依赖，简化为mock——这个模块提供了非常强大并且有用的方法，通过它们可以模拟或者屏敝掉这些不受我们希望的方面。
注意：mock是最近收录在Python 3.3标准库中的；之前发布的版本必须通过 PyPI下载Mock库。
恐惧系统调用
再举一个例子，考虑系统调用，我们将在余下的文章中讨论它们。不难发现，这些都可以考虑使用模拟：无论你是想写一个脚本弹出一个CD驱动，或者是一个web服务用来删除/tmp目录下的缓存文件，或者是一个socket服务来绑定一个TCP端口，这些调用都是在你单元测试的时候是不被希望的方面。
作为一个开发人员，你更关心你的库是不是成功的调用了系统函数来弹出CD，而不是体验每次测试的时候CD托盘都打开。
作为一个开发人员，你更关心你的库是不是成功调用了系统函数来弹出CD（带着正确的参数等）。而不是体验每次测试的时候CD托盘都打开（或者更糟，很多次，当一个单元测试运行的时候，很多测试点都涉及到了弹出代码）。
同样地，保持你的单元测试效率和性能意味着要还要保留一些自动化测试之外的“缓慢代码”，比如文件系统和网络的访问。
一个简单的删除功能
有时，我们需要从文件系统中删除文件，因此，我们可以写这样的一个函数在Python中，这个函数将使它更容易成为我们的脚本去完成这件事情。
#!/usr/bin/env python # -*- coding: utf-8 -*- import os def rm(filename): os.remove(filename) |
很明显，在这个时间点上，我们的rm方法不提供比基本os.remove方法更多的功能，但我们的代码将会有所改进，允许我们在这里添加更多的功能。
让我们写一个传统的测试用例，即，不用模拟测试：
#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import os.path import tempfile import unittestclass RmTestCase(unittest.TestCase): tmpfilepath = os.path.join(tempfile.gettempdir(), "tmp-testfile") def setUp(self): with open(self.tmpfilepath, "wb") as f: f.write("Delete me!") def test_rm(self): # remove the file rm(self.tmpfilepath) # test that it was actually removed self.assertFalse(os.path.isfile(self.tempfile), "Failed to remove the file.") |
我们的测试用例是相当简单的，但当它每次运行时，一个临时文件被创建然后被删除。此外，我们没有办法去测试我们的rm方法是否传递参数到os.remove中。我们可以假设它是基于上面的测试，但仍有许多需要被证实。
