进行单元测试可以提高代码质量，并且它不会打断你的工作流。本文是 使用 CMake 和 VSCodium 设置一个构建系统 的后续文章。在上一篇文章中我介绍了基于 VSCodium 和 CMake 配置构建系统。本文我将介绍如何通过 GoogleTest 和 CTest 将单元测试集成到这个构建系统中。首先克隆 这个仓库，用 VSCodium 打开，切换到 devops_2 标签。你可以通过点击 main 分支符号（红框处），然后选择 devops_2 标签（黄框处）来进行切换：或者你可以通过命令行来切换：$ git checkout tags/devops_2 GoogleTestGoogleTest 是一个平台无关的开源 C++ 测试框架。单元测试是用来验证单个逻辑单元的行为的。尽管 GoogleTest 并不是专门用于单元测试的，我将用它对 Generator 库进行单元测试。在 GoogleTest 中，测试用例是通过断言宏来定义的。断言可能产生以下结果：成功: 测试通过。非致命失败: 测试失败，但测试继续。致命失败: 测试失败，且测试终止。致命断言和非致命断言通过不同的宏来区分：ASSERT_*： 致命断言，失败时终止。EXPECT_*： 非致命断言，失败时不终止。谷歌推荐使用 EXPECT_* 宏，因为当测试中包含多个的断言时，它允许继续执行。断言有两个参数：第一个参数是测试分组的名称，第二个参数是测试自己的名称。Generator 只定义了 generate(...) 函数，所以本文中所有的测试都属于同一个测试组：GeneratorTest。针对 generate(...) 函数的测试可以从 GeneratorTest.cpp 中找到。引用一致性检查generate(...) 函数有一个 std::stringstream 的引用作为输入参数，并且它也将这个引用作为返回值。第一个测试就是检查输入的引用和返回的引用是否一致。TEST(GeneratorTest, ReferenceCheck){ const int NumberOfElements = 10; std::stringstream buffer; EXPECT_EQ( std::addressof(buffer), std::addressof(Generator::generate(buffer, NumberOfElements)) ); } 在这个测试中我使用 std::addressof 来获取对象的地址，并用 EXPECT_EQ 来比较输入对象和返回对象是否是同一个。检查元素个数本测试检查作为输入的 std::stringstream 引用中的元素个数与输入参数中指定的个数是否相同。TEST(GeneratorTest, NumberOfElements){ const int NumberOfElements = 50; int nCalcNoElements = 0; std::stringstream buffer; Generator::generate(buffer, NumberOfElements); std::string s_no; while(std::getline(buffer, s_no, ' ')) { nCalcNoElements++; } EXPECT_EQ(nCalcNoElements, NumberOfElements); } 乱序重排本测试检查随机化引擎是否工作正常。如果连续调用两次 generate 函数，应该得到的是两个不同的结果。TEST(GeneratorTest, Shuffle){ const int NumberOfElements = 50; std::stringstream buffer_A; std::stringstream buffer_B; Generator::generate(buffer_A, NumberOfElements); Generator::generate(buffer_B, NumberOfElements); EXPECT_NE(buffer_A.str(), buffer_B.str()); } 求和校验与前面的测试相比，这是一个大体量的测试。它检查 1 到 n 的数值序列的和与乱序重排后的序列的和是否相等。 generate(...) 函数应该生成一个 1 到 n 的乱序的序列，这个序列的和应当是不变的。TEST(GeneratorTest, CheckSum){ const int NumberOfElements = 50; int nChecksum_in = 0; int nChecksum_out = 0; std::vector<int> vNumbersRef(NumberOfElements); // Input vector std::iota(vNumbersRef.begin(), vNumbersRef.end(), 1); // Populate vector // Calculate reference checksum for(const int n : vNumbersRef){ nChecksum_in += n; } std::stringstream buffer; Generator::generate(buffer, NumberOfElements); std::vector<int> vNumbersGen; // Output vector std::string s_no; // Read the buffer back back to the output vector while(std::getline(buffer, s_no, ' ')) { vNumbersGen.push_back(std::stoi(s_no)); } // Calculate output checksum for(const int n : vNumbersGen){ nChecksum_out += n; } EXPECT_EQ(nChecksum_in, nChecksum_out); } 你可以像对一般 C++ 程序一样调试这些测试。CTest除了嵌入到代码中的测试之外，CTest 提供了可执行程序的测试方式。简而言之就是通过给可执行程序传入特定的参数，然后用 正则表达式 对它的输出进行匹配检查。通过这种方式可以很容易检查程序对于不正确的命令行参数的反应。这些测试定义在顶层的 CMakeLists.txt 文件中。下面我详细介绍 3 个测试用例：参数正常如果输入参数是一个正整数，程序应该输出应该是一个数列：add_test(NAME RegularUsage COMMAND Producer 10) set_tests_properties(RegularUsage PROPERTIES PASS_REGULAR_EXPRESSION "^[0-9 ]+" ) 没有提供参数如果没有传入参数，程序应该立即退出并提示错误原因：add_test(NAME NoArg COMMAND Producer) set_tests_properties(NoArg PROPERTIES PASS_REGULAR_EXPRESSION "^Enter the number of elements as argument" ) 参数错误当传入的参数不是整数时，程序应该退出并报错。比如给 Producer 传入参数 ABC：add_test(NAME WrongArg COMMAND Producer ABC) set_tests_properties(WrongArg PROPERTIES PASS_REGULAR_EXPRESSION "^Error: Cannot parse" ) 执行测试可以使用 ctest -R Usage -VV 命令来执行测试。这里给 ctest 的命令行参数：-R <测试名称> : 执行单个测试-VV：打印详细输出测试执行结果如下：$ ctest -R Usage -VV UpdatecTest Configuration from :/home/stephan/Documents/cpp_testing sample/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/stephan/Documents/cpp_testing sample/build/DartConfiguration.tcl Test project /home/stephan/Documents/cpp_testing sample/build Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end 在这里我执行了名为 Usage 的测试。它以无参数的方式调用 Producer：test 3 Start 3: Usage 3: Test command: /home/stephan/Documents/cpp testing sample/build/Producer 输出不匹配 [^[0-9]+] 的正则模式，测试未通过。3: Enter the number of elements as argument 1/1 test #3. Usage ................ Failed Required regular expression not found. Regex=[^[0-9]+] 0.00 sec round. 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.00 sec The following tests FAILED: 3 - Usage (Failed) Errors while running CTest $ 如果想要执行所有测试（包括那些用 GoogleTest 生成的），切换到 build 目录中，然后运行 ctest 即可：在 VSCodium 中可以通过点击信息栏的黄框处来调用 CTest。如果所有测试都通过了，你会看到如下输出：使用 Git 钩子进行自动化测试目前为止，运行测试是开发者需要额外执行的步骤，那些不能通过测试的代码仍然可能被提交和推送到代码仓库中。利用 Git 钩子 可以自动执行测试，从而防止有瑕疵的代码被提交。切换到 .git/hooks 目录，创建 pre-commit 文件，复制粘贴下面的代码：#!/usr/bin/sh (cd build; ctest --output-on-failure -j6) 然后，给文件增加可执行权限：$ chmod +x pre-commit 这个脚本会在提交之前调用 CTest 进行测试。如果有测试未通过，提交过程就会被终止：只有所有测试都通过了，提交过程才会完成：这个机制也有一个漏洞：可以通过 git commit --no-verify 命令绕过测试。解决办法是配置构建服务器，这能保证只有正常工作的代码才能被提交，但这又是另一个话题了。总结本文提到的技术实施简单，并且能够帮你快速发现代码中的问题。做单元测试可以提高代码质量，同时也不会打断你的工作流。GoogleTest 框架提供了丰富的特性以应对各种测试场景，文中我所提到的只是一小部分而已。如果你想进一步了解 GoogleTest，我推荐你阅读 GoogleTest Primer。（题图：MJ/f212ce43-b60b-4005-b70d-8384f2ba5860）via: https://opensource.com/article/22/1/unit-testing-googletest-ctest作者：Stephan Avenwedde 选题：lujun9972 译者：toknow-gh 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Python 单元测试：assertTrue 是真值，assertFalse 是假值
在这篇文章中，我们将介绍单元测试的布尔断言方法 assertTrue 和 assertFalse 与身份断言 assertIs 之间的区别。定义下面是目前单元测试模块文档中关于 assertTrue 和 assertFalse 的说明，代码进行了高亮：assertTrue(expr, msg=None)assertFalse(expr, msg=None)测试该表达式是真值（或假值）。注：这等价于bool(expr) is True而不等价于expr is True（后一种情况请使用 assertIs(expr, True)）。Mozilla 开发者网络中定义 真值 如下：在一个布尔值的上下文环境中能变成“真”的值在 Python 中等价于：bool(expr) is True 这个和 assertTrue 的测试目的完全匹配。因此该文档中已经指出 assertTrue 返回真值，assertFalse 返回假值。这些断言方法从接受到的值构造出一个布尔值，然后判断它。同样文档中也建议我们根本不应该使用 assertTrue 和 assertFalse。在实践中怎么理解？我们使用一个非常简单的例子 - 一个名称为 always_true 的函数，它返回 True。我们为它写一些测试用例，然后改变代码，看看测试用例的表现。作为开始，我们先写两个测试用例。一个是“宽松的”：使用 assertTrue 来测试真值。另外一个是“严格的”：使用文档中建议的 assertIs 函数。import unittest from func import always_true class TestAlwaysTrue(unittest.TestCase): def test_assertTrue(self): """ always_true returns a truthy value """ result = always_true() self.assertTrue(result) def test_assertIs(self): """ always_true returns True """ result = always_true() self.assertIs(result, True) 下面是 func.py 中的非常简单的函数代码：def always_true(): """ I'm always True. Returns: bool: True """ return True 当你运行时，所有测试都通过了：always_true returns True ... ok always_true returns a truthy value ... ok ---------------------------------------------------------------------- Ran 2 tests in 0.004s OK 开心ing~现在，某个人将 always_true 函数改变成下面这样：def always_true(): """ I'm always True. Returns: bool: True """ return 'True' 它现在是用返回字符串 "True" 来替代之前反馈的 True （布尔值）。（当然，那个“某人”并没有更新文档 - 后面我们会增加难度。）这次结果并不如开心了：always_true returns True ... FAIL always_true returns a truthy value ... ok ====================================================================== FAIL: always_true returns True ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/assertttt/test.py", line 22, in test_is_true self.assertIs(result, True) AssertionError: 'True' is not True ---------------------------------------------------------------------- Ran 2 tests in 0.004s FAILED (failures=1) 只有一个测试用例失败了！这意味着 assertTrue 给了我们一个 误判 （ false-positive ） 。在它不应该通过测试时，它通过了。很幸运的是我们第二个测试是使用 assertIs 来写的。因此，跟手册上了解到的信息一样，为了保证 always_true 的功能和更严格测试的结果保持一致，应该使用 assertIs 而不是 assertTrue。使用断言的辅助方法使用 assertIs 来测试返回 True 和 False 来冗长了。因此，如果你有个项目需要经常检查是否是返回了 True 或者 False，那们你可以自己编写一些断言的辅助方法。这好像并没有节省大量的代码，但是我个人觉得提高了代码的可读性。def assertIsTrue(self, value): self.assertIs(value, True) def assertIsFalse(self, value): self.assertIs(value, False) 总结一般来说，我的建议是让测试越严格越好。如果你想测试 True 或者 False，听从文档的建议，使用 assertIs。除非不得已，否则不要使用 assertTrue 和 assertFalse。如果你面对的是一个可以返回多种类型的函数，例如，有时候返回布尔值，有时候返回整形，那么考虑重构它。这是代码的异味。在 Python 中，抛出一个异常比使用 False 表示错误更好。此外，如果你确实想使用断言来判断函数的返回值是否是真，可能还存在第二个代码异味 - 代码是正确封装了吗？如果 assertTrue 和 assertFalse 是根据正确的 if 语句来执行，那么值得检查下你是否把所有你想要的东西都封装在合适的位置。也许这些 if 语句应该封装在测试的函数中。测试开心！via: http://jamescooke.info/python-unittest-asserttrue-is-truthy-assertfalse-is-falsy.html作者：James Cooke 译者：chunyang-wen 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
本文讲述的是 Python 中 Mock 的使用。如何执行单元测试而不用考验你的耐心很多时候，我们编写的软件会直接与那些被标记为“垃圾”的服务交互。用外行人的话说：服务对我们的应用程序很重要，但是我们想要的是交互，而不是那些不想要的副作用，这里的“不想要”是在自动化测试运行的语境中说的。例如：我们正在写一个社交 app，并且想要测试一下 "发布到 Facebook" 的新功能，但是不想每次运行测试集的时候真的发布到 Facebook。Python 的 unittest 库包含了一个名为 unittest.mock 或者可以称之为依赖的子包，简称为 mock —— 其提供了极其强大和有用的方法，通过它们可以 模拟 （ mock ） 并去除那些我们不希望的副作用。注意：mock 最近被收录到了 Python 3.3 的标准库中；先前发布的版本必须通过 PyPI 下载 Mock 库。恐惧系统调用再举另一个例子，我们在接下来的部分都会用到它，这是就是系统调用。不难发现，这些系统调用都是主要的模拟对象：无论你是正在写一个可以弹出 CD 驱动器的脚本，还是一个用来删除 /tmp 下过期的缓存文件的 Web 服务，或者一个绑定到 TCP 端口的 socket 服务器，这些调用都是在你的单元测试上下文中不希望产生的副作用。作为一个开发者，你需要更关心你的库是否成功地调用了一个可以弹出 CD 的系统函数（使用了正确的参数等等），而不是切身经历 CD 托盘每次在测试执行的时候都打开了。（或者更糟糕的是，弹出了很多次，在一个单元测试运行期间多个测试都引用了弹出代码！）同样，保持单元测试的效率和性能意味着需要让如此多的“缓慢代码”远离自动测试，比如文件系统和网络访问。对于第一个例子来说，我们要从原始形式换成使用 mock 重构一个标准 Python 测试用例。我们会演示如何使用 mock 写一个测试用例，使我们的测试更加智能、快速，并展示更多关于我们软件的工作原理。一个简单的删除函数我们都有过需要从文件系统中一遍又一遍的删除文件的时候，因此，让我们在 Python 中写一个可以使我们的脚本更加轻易完成此功能的函数。#!/usr/bin/env python # -*- coding: utf-8 -*- import os def rm(filename): os.remove(filename) 很明显，我们的 rm 方法此时无法提供比 os.remove 方法更多的相关功能，但我们可以在这里添加更多的功能，使我们的基础代码逐步改善。让我们写一个传统的测试用例，即，没有使用 mock：#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import os.path import tempfile import unittest class 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.tmpfilepath), "Failed to remove the file.") 我们的测试用例相当简单，但是在它每次运行的时候，它都会创建一个临时文件并且随后删除。此外，我们没有办法测试我们的 rm 方法是否正确地将我们的参数向下传递给 os.remove 调用。我们可以基于以上的测试认为它做到了，但还有很多需要改进的地方。使用 Mock 重构让我们使用 mock 重构我们的测试用例：#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import mock import unittest class RmTestCase(unittest.TestCase): @mock.patch('mymodule.os') def test_rm(self, mock_os): rm("any path") # test that rm called os.remove with the right parameters mock_os.remove.assert_called_with("any path") 使用这些重构，我们从根本上改变了测试用例的操作方式。现在，我们有一个可以用于验证其他功能的内部对象。潜在陷阱第一件需要注意的事情就是，我们使用了 mock.patch 方法装饰器，用于模拟位于 mymodule.os 的对象，并且将 mock 注入到我们的测试用例方法。那么只是模拟 os 本身，而不是 mymodule.os 下 os 的引用（LCTT 译注：注意 @mock.patch('mymodule.os') 便是模拟 mymodule.os 下的 os），会不会更有意义呢？当然，当涉及到导入和管理模块，Python 的用法就像蛇一样灵活。在运行时，mymodule 模块有它自己的被导入到本模块局部作用域的 os。因此，如果我们模拟 os，我们是看不到 mock 在 mymodule 模块中的模仿作用的。这句话需要深刻地记住：模拟一个东西要看它用在何处，而不是来自哪里。如果你需要为 myproject.app.MyElaborateClass 模拟 tempfile 模块，你可能需要将 mock 用于 myproject.app.tempfile，而其他模块保持自己的导入。先将那个陷阱放一边，让我们继续模拟。向 ‘rm’ 中加入验证之前定义的 rm 方法相当的简单。在盲目地删除之前，我们倾向于验证一个路径是否存在，并验证其是否是一个文件。让我们重构 rm 使其变得更加智能：#!/usr/bin/env python # -*- coding: utf-8 -*- import os import os.path def rm(filename): if os.path.isfile(filename): os.remove(filename) 很好。现在，让我们调整测试用例来保持测试的覆盖率。#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import mock import unittest class RmTestCase(unittest.TestCase): @mock.patch('mymodule.os.path') @mock.patch('mymodule.os') def test_rm(self, mock_os, mock_path): # set up the mock mock_path.isfile.return_value = False 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 rm("any path") mock_os.remove.assert_called_with("any path") 我们的测试用例完全改变了。现在我们可以在没有任何副作用的情况下核实并验证方法的内部功能。将文件删除作为服务到目前为止，我们只是将 mock 应用在函数上，并没应用在需要传递参数的对象和实例的方法上。我们现在开始涵盖对象的方法。首先，我们将 rm 方法重构成一个服务类。实际上将这样一个简单的函数转换成一个对象，在本质上这不是一个合理的需求，但它能够帮助我们了解 mock 的关键概念。让我们开始重构：#!/usr/bin/env python # -*- coding: utf-8 -*- import os import os.path class RemovalService(object): """A service for removing objects from the filesystem.""" def rm(filename): if os.path.isfile(filename): os.remove(filename) 你会注意到我们的测试用例没有太大变化：#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import RemovalService import mock import unittest class 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") 很好，我们知道 RemovalService 会如预期般的工作。接下来让我们创建另一个服务，将 RemovalService 声明为它的一个依赖：#!/usr/bin/env python # -*- coding: utf-8 -*- import os import os.path class RemovalService(object): """A service for removing objects from the filesystem.""" def rm(self, filename): if os.path.isfile(filename): os.remove(filename) class UploadService(object): def __init__(self, removal_service): self.removal_service = removal_service def upload_complete(self, filename): self.removal_service.rm(filename) 因为我们的测试覆盖了 RemovalService，因此我们不会对我们测试用例中 UploadService 的内部函数 rm 进行验证。相反，我们将调用 UploadService 的 RemovalService.rm 方法来进行简单测试（当然没有其他副作用），我们通过之前的测试用例便能知道它可以正确地工作。这里有两种方法来实现测试：模拟 RemovalService.rm 方法本身。在 UploadService 的构造函数中提供一个模拟实例。因为这两种方法都是单元测试中非常重要的方法，所以我们将同时对这两种方法进行回顾。方法 1：模拟实例的方法mock 库有一个特殊的方法装饰器，可以模拟对象实例的方法和属性，即 @mock.patch.object decorator 装饰器：#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import RemovalService, UploadService import mock import unittest class 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") 非常棒！我们验证了 UploadService 成功调用了我们实例的 rm 方法。你是否注意到一些有趣的地方？这种修补机制（patching mechanism）实际上替换了我们测试用例中的所有 RemovalService 实例的 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 的工作方式所导致的。这里是使用多个装饰器的情况下它们执行顺序的伪代码：patch_sys(patch_os(patch_os_path(test_something))) 因为 sys 补丁位于最外层，所以它最晚执行，使得它成为实际测试方法参数的最后一个参数。请特别注意这一点，并且在运行你的测试用例时，使用调试器来保证正确的参数以正确的顺序注入。方法 2：创建 Mock 实例我们可以使用构造函数为 UploadService 提供一个 Mock 实例，而不是模拟特定的实例方法。我更推荐方法 1，因为它更加精确，但在多数情况，方法 2 或许更加有效和必要。让我们再次重构测试用例：#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import RemovalService, UploadService import mock import unittest class 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") 在这个例子中，我们甚至不需要修补任何功能，只需为 RemovalService 类创建一个 auto-spec，然后将实例注入到我们的 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 value def 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 facebook class 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) 这是我们的测试用例，它可以检查我们发布的消息,而不是真正地发布消息：import facebook import simple_facebook import mock import unittest class 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 总结即使对它的使用还有点不太熟悉，对单元测试来说，Python 的 mock 库可以说是一个规则改变者。我们已经演示了常见的用例来了解了 mock 在单元测试中的使用，希望这篇文章能够帮助 Python 开发者克服初期的障碍，写出优秀、经受过考验的代码。via: https://www.toptal.com/python/an-introduction-to-mocking-in-python作者：NAFTULI TZVI KAY 译者：cposture 校对：wxy本文由 LCTT 原创翻译，Linux中国 荣誉推出