python 模块的单元测试基础设施

Question

我正在编写一个 python 模块，我想对其进行单元测试。我是 python 新手，对可用的选项有些困惑。

目前，我想将我的测试编写为 doctests 因为我喜欢声明式而不是命令式风格（但是，如果我的这种偏好被误导，请随时纠正我）。然而，这提出了一些问题：

1. 我应该把测试放在哪里？在与他们正在测试的代码相同的文件中（或在文档测试的文档字符串中）？或者将它们分开到自己的目录中是否被认为更好？
2. 如何从命令行一次性运行整个模块中的所有测试？
3. 如何报告测试套件的代码覆盖率？
4. 对于 python 中的单元测试，我还应该了解其他最佳实践吗？

Answer 1

请随意纠正我的观点
如果信息有误，则偏好

我比任何其他开源开发人员更广泛地使用了 doctest（方式 扩展了其预期使用边界），至少在单个项目中是这样 - < em>所有我的gmpy项目中的测试都是文档测试。在 gmpy 刚开始时它是全新的，这似乎是一个很棒的小技巧，如果某件事值得做，那么就值得过度做 - 对吗？-）

错了。除了 gmpy 之外，将所有内容重做为正确的单元测试会带来太多的返工，我再也没有犯过这样的错误：这些天，我使用单元测试作为单元测试，而文档测试只是为了检查我的文档，因为它们一直是用来使用的。文档测试所做的（将预期结果与实际结果进行比较——仅此而已）并不是构建可靠的测试套件的良好或合理的基础。它从来没有其他意图。

我建议您查看nose。新的 Python 2.7 中的 unittest 模块更丰富、更好，如果您坚持使用 2.4、2.5 或 2.6，您仍然可以通过 unittest2 您可以下载并安装； nose 很好地补充了 unittest。

如果你无法忍受单元测试（但是——尝试一下，它会在你身上成长！-），也许可以尝试 py.test，一个具有完全不同理念的替代包。

但是，请，不要使用 doctest 来测试文档中示例以外的内容！精确相等的比较经常会阻碍你，因为我不得不以我的（隐喻性的；-）代价在gmpy中学习......

Answer 2

我不喜欢文档测试，原因如下：

• 您无法运行测试的子集。当测试失败时，仅运行一个测试很有用。 Doctest 没有提供这样做的方法。
• 如果在文档测试过程中发生故障，整个事情就会停止。我宁愿查看所有结果来决定如何解决破损问题。
• 编码风格是程式化的，并且必须具有可打印的结果。
• 您的代码以特殊方式执行，因此更难推理它将如何执行，更难添加帮助程序，更难围绕测试进行编程。

此列表取自我的博客文章 关于 doctest 我不喜欢的事情，其中还有更多，还有一长串评论讨论这些观点。

关于覆盖率：我不认为 Python 中有一个覆盖率工具可以测量文档测试中的覆盖率。但由于它们只是很长的语句列表，没有分支或循环，这是一个问题吗？

Answer 3

我怀疑 Alex 在程序员的曲线上可能比我领先一些，但如果你想要有一些 Python 经验的人的观点（作为“用户”而不是专家或传播者），但又不一样联盟，我对单元测试的发现几乎相同。

一开始，文档测试对于简单的测试来说可能听起来很棒，我在家里的一些个人项目中朝着这个方向发展，因为它在其他地方被推荐了。
在工作中我们使用鼻子（尽管如此封闭和包裹，我的印象是我们直到不久前才使用 pyUnit），几个月前我在家也开始使用鼻子。

初始设置时间和管理开销，以及与实际代码的分离，一开始似乎是不必要的，特别是当您测试代码库不是那么大的东西时，但从长远来看，我发现文档测试越来越以我想做的每一次重构或重组的方式，相当难以维护，几乎不可能扩展，并且很快就抵消了最初的节省。是的，我知道单元测试与集成测试不同，但文档测试往往会过于严格地为您定义单元。
如果您认为它是有效的草图工具或开发模型，它们也不太适合基于单元的敏捷。

您可能需要花一些时间来计划，然后按照 pyUnit 或鼻子引导您的方式完善您的单元测试，但即使在短期内，您也可能会发现它实际上在很多层面上都在帮助您。我知道它对我有用，而且我对这些天正在处理的代码库的复杂性和规模还比较陌生。前几周你必须咬紧牙关。

Answer 4

有关覆盖范围，请查看优秀的 coverage.py。

除此之外，亚历克斯·马尔泰利写的所有内容都非常切题。

Answer 5

doctests 非常适合快速、小型的单元测试，它描述了相关对象的一些基本用法（因为它们出现在文档字符串中，因此还有帮助（无论如何）等）。

我个人发现使用unittest模块进行广泛和更彻底的测试会更有效，现在2.7模块（向后移植到unittest2）具有更方便的断言。您可以使用单元测试框架设置测试套件和任意复杂的场景，并一次性覆盖所有不同的测试（命令行）

coverage.py，由 Ned Batchelder 和 @bstpierre 提到的将与其中任何一个一起使用，我推荐它来查看您对代码进行了测试以及什么没有。您可以将其添加到 CI 系统（即 Hudson 或任何您喜欢使用的系统）中，以了解已覆盖和未覆盖的内容，并且 HTML 报告非常适合查看测试覆盖范围内未命中的内容。 Coverage 支持 Junit xml 输出，许多 CI 系统都知道如何提供图表化的持续结果，让您看到构建随着时间的推移变得更好或更差。

Answer 6

我同意上述关于 doctest 不扩展的所有观点，并且我更喜欢坚持使用 unittest。

我可以贡献的一个技巧是从处理 __name__ == "__main__ 的代码中调用单元测试，因此如果测试文件作为脚本运行，它将运行其测试。

例如：

#!/usr/bin/env python

"""
Unit tests for the GetFiles.py utility
"""

import unittest
from FileUtilities import getTree

class TestFileUtilities(unittest.TestCase):

   def testGetTree(self):
      """
      Tests that a known tree is found and incidentally confirms
      that we have the tree we expected to use for our current
      sample extraction.
      """
      found = getTree('./anzmeta-dtd', '.pen')
      expected_path_tail = ['ISOdia.pen',
                       'ISOgrk1.pen',
                       'ISOtech.pen']
      for i, full_path in enumerate(found):
         assert full_path.endswith( expected_path_tail[i] ), expected_path_tail[i]

# other tests elided         

if __name__ == "__main__":
   # When this module is executed from the command-line, run all its tests
   unittest.main()