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

Question

我正在编写一个python模块，我想对它进行单元测试。我对python还不熟悉，对可用的选项有些迷惑。在

目前，我想把我的测试写成doctests，因为我喜欢声明式的而不是命令式的风格（但是，如果这个偏好是错误的，请不要打扰我）。然而，这引发了一些问题：

1. 我应该把测试放在哪里？在与他们测试的代码相同的文件中（或者在docstring中用于doctest）？还是把它们分开放在自己的目录中比较好？在
2. 如何从命令行一次性运行整个模块中的所有测试？在
3. 如何报告测试套件的代码覆盖率？在
4. 对于python中的单元测试，还有其他我应该知道的最佳实践吗？在

Answer 1

我怀疑Alex在程序员的发展道路上可能比我领先一点，但是如果你想从一个有Python经验的人（作为“用户”而不是专家或传道者）的角度来看，我对单元测试的发现几乎是一样的。在

博士学位在一开始听起来很适合简单的测试，而我在国内的一些个人项目中也朝着这个方向发展，因为它在其他地方被推荐过。 在工作中，我们使用鼻子（虽然如此罐装和包装，我的印象是我们一直使用pyUnit，直到不久前），几个月前，我也搬到了家里的鼻子。在

最初的设置时间和管理开销，以及与实际代码的分离，在一开始可能看起来是不必要的，尤其是当您测试的是不是很大的代码库时，但是从长远来看，我发现doctest阻碍了我想要进行的每一次重构或重组，很难维持，几乎不可能扩大规模，而且很快就抵消了最初的节省。是的，我知道单元测试与集成测试不同，但是doctest倾向于为您定义单元过于严格。 如果你认为它是一个有效的草图工具或开发模型，它们也不太适合基于单元的敏捷。在

也许你需要一点时间来计划和完善你的单元测试，就像pyUnit或nose引导你去做的那样，但是很有可能即使在短期内你也会发现它实际上在很多方面帮助你。我知道这对我很有用，而且我对这些天我正在工作的代码库的复杂性和规模还比较陌生。刚开始的几个星期就得咬紧牙关。在

Answer 2

feel free to disabuse me of this preference if it is misinformed

我相信我使用doctest比任何其他开源开发人员都更广泛（方式扩展其预期用途边界），至少在单个项目中--所有我的gmpy项目中的测试都是doctest。它在gmpy开始的时候是全新的，它似乎是一个很好的小把戏，如果某件事值得去做，它就值得做得过多——对吗？-)在

错了。除了gmpy之外，在这里重新做所有的正确的单元测试会有太多的返工，我从来没有犯过这样的错误：现在，我使用单元测试作为单元测试，而doctest只是为了检查我的文档，因为它们一直都是要被使用的。博士所做的（将预期结果与实际结果进行相等性比较——仅此而已）并不是构建可靠测试套件的良好或可靠的基础。从来没有其他打算。在

我建议你看看nose。新Python2.7中的unittest模块更丰富、更好，如果您停留在2.4、2.5或2.6中，您仍然可以使用带有unittest2的新功能，您可以下载并安装；nose很好地补充了unittest。在

如果你不能忍受unittest（但是——试试看，它会在你身上成长！-)，也许可以试试py.test，一个有着完全不同理念的替代包。在

但是，请，不要拉伸doctest来测试文档中示例以外的内容！确切的平等比较经常会妨碍你，因为我在gmpy中花了我的（隐喻；-）费用来学习。。。在

Answer 3

我不喜欢医生，原因如下：

• 不能运行测试的子集。当一个测试失败时，只运行一个测试是很有用的。Doctest无法做到这一点。在
• 如果整个失败发生在中间，那就停止了。我宁愿看所有的结果来决定如何处理破损。在
• 编码样式是样式化的，并且必须有可打印的结果。在
• 你的代码是以一种特殊的方式执行的，所以很难解释它将如何执行，更难添加助手，更难围绕测试进行编程。在

这个列表取自我的博客文章Things I don't like about doctest，这里还有更多，还有一长串的评论在讨论这些观点。在

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