Python：进行“单元测试”吗？有一些“文档测试”的东西没有吗？
问题很清楚，...但请注意，我不是在问功能比较（已经有很多功能比较），也不是在问您更喜欢哪一个！
我自己对文档测试有明显的偏好，我将它们用于所有事情，即使它们不用于文档。但我想知道的是：是否有任何你可以用unitests做但不能用doctests做的事情？？？
The question is quite clear, ... note however that I am NOT asking about a feature comparison (there are a lot of them already), nor am I asking about which one you prefer !
I have myself a clear preference for doctests, I use them for everything, even if those are not to be used for documentation. But what I am wondering is : is there anything you can do with unitests that you cannot do with doctests ???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
人们普遍存在一种误解，认为 doctest 是用于测试代码的。 doctest 旨在测试您的文档。 doctest 旨在测试您的文档是否与函数/类/模块实际执行的操作相匹配，并在文档中的示例代码随着模块的发展而过时时向您发出警报。
虽然 doctest 可能会揭示代码中的错误，但这不是其主要目的（例如，代码的更改可能会解决单元测试的测试用例代码中的错误，但测试测试用例代码不是单元测试的主要目的）
字符串也会通过 help() 函数自动提取出来，成为您的文档
函数/类/模块；你不能把文档字符串变成文档。你的模块/函数/类的用户（或者几天后的你）可能会尝试对你的函数/类/模块执行 help() ，并惊讶地发现文档是一堆代码。
There is a widespread misconception that doctest is for testing your code. doctest is intended for testing your documentation. doctest is intended to test that your documentation matches what the function/class/module is actually doing, and alerts you if sample code in your documentation becomes obsolete as the module evolves.
While doctest might reveal bugs in the code, it is not its primary purpose (e.g. like a change in code might unravel bugs in a unittest's testcase code, but testing the testcase code is not unitetest's primary purpose)
docstring are automatically extracted out by help() function to become documentation for your
function/class/module; you cannot make a docstring not a documentation. Users of your module/function/class (or you in a few days) might try to do help() on your function/class/module and get a surprise that the documentation is a bunch of codes.
有一些测试场景文档测试根本不能很好地涵盖。这没关系，因为正如 Lie 指出的那样，文档测试并不是一个全面的测试解决方案 - 它们的目的是确保文档中的简单交互式提示样式示例（包括文档字符串）不会过时。
另一方面，编写实际的单元测试可以让您充分发挥 Python 的全部功能来决定如何编写测试套件（例如，使用继承不仅可以共享测试设置和拆卸操作，还可以共享实际的测试方法）。
文档测试可能是其中的一部分，但它们不是完整的测试解决方案（除了小型的、相对独立的操作）。
浏览 Python 自己的测试套件（
test包）并查看其中的一些测试可能是值得的。虽然文档测试发挥了作用，但大部分都是使用unittest编写的。There are some test scenarios doctests simply don't cover very well. That's OK since, as Lie pointed out, doctests aren't meant to be a comprehensive testing solution - they're meant to ensure that simple interactive-prompt style examples in your documentation (including docstrings) don't get out of date.
Writing actual unit tests, on the other hand, allows you to unlimber the full power of Python in deciding how to compose your test suite (e.g. using inheritance to share not only test set up and tear down operations, but also actual test methods).
doctests may be a part of that, but they aren't a complete testing solution (except for small, relatively self-contained operations).
It's probably worth browsing Python's own test suite (the
testpackage) and taking a look at some of the tests in there. While doctests play their part, most of it is written usingunittest.文档测试仅限于每个功能（或每个类）测试。你不能做一些事情，比如获取一个函数的输出并尝试另一个函数等。它最好用于“示例”类型测试（即我如何使用这个函数？）
单元测试可以比文档测试更大、更复杂。
Doctests are limited to per function (or per class) tests. You cannot do things like taking the output of one function and trying it with another etc. It's best used for "example" type tests (i.e. how do I use this function?)
Unit tests can be larger and more involved than doctests.
有些测试需要诸如数据库设置和初始化之类的东西。
这可能会使文档测试：
文档）；并且
为每个函数或类建立数据库。相比之下，
单元测试更容易可以使用
使用同一个数据库来测试许多功能
或课程。
Some tests will need things like databases set up and initialised.
This could make doctests:
documentation); and
up the database for each function or class. In comparison,
unit tests more easily could use the
same database to test many functions
or classes.