我所参与的项目的开发人员认为，doctests与单元测试一样好，并且如果一段代码被证明，则不需要进行单元测试。我不相信这是事实。任何人都可以提供一些可靠的，理想上引用的例子来支持或反对doctests取代单元测试需求的论点吗？
谢谢 -Daniel
编辑：任何人都可以提供一个参考，表明doctesting不应该取代单元测试吗？答案 0 :(得分：20)
我（ab）使用doctest代替unittest，当我多年前开始我的gmpy项目时，你可以浏览它的来源并看到所有功能都是通过doctests进行了彻底的测试（功能由C编码的Python扩展提供，上次我为覆盖测量进行了检测，我的覆盖率超过95％）。我为什么这样做？因为doctest是全新的，gmpy也是如此，我很想知道我能推动多远。
答案：确实很远 - 但绝对不值得（新奇感消失，但你不想重写所有的测试，这就是为什么gmpy的测试仍然是全文测试的原因）。医生的极端脆弱性，即使在信息中最微小的拼写错误也会破坏测试，当他们被这种方式滥用时，真的很麻烦。这有点像传统的集成测试，基于比较输出和“黄金”（已知良好）的预期输出：第一次容易写，但在几年修复无偿测试中断后你会悠闲地忏悔; - ）。
如果您发现unittest的样式很繁琐，那么还有其他优秀的替代品仍然意味着用于单元测试，例如py.test和{{3} } - doctest实际上是出于不同的目的（支持文档，而不是通用的单元测试），而且当然值得添加您为文档目的编写的任何doctests 到您的测试中电池，不值得用它替换单元测试的测试维护难题。
答案 1 :(得分：6)
确实没有支持或反对doc测试的论据。它们只是测试。事实上，从python 2.4开始，有一种方法可以从你的doctests创建单元测试服： http://docs.python.org/library/doctest.html#unittest-api
从某种意义上说，你可以将doc-tests视为单元测试的一个子集，至少从功能的角度来看。
然而，python文档建议将doctests用于以下内容：
他们的论点是，如果你在文档中编写测试，你将被迫编写更好的文档和测试。与单独编写单元测试相反 - 您很少添加足够的文档，而且它们往往会停滞不前并且过时。
请参阅： http://docs.python.org/library/doctest.html#soapbox
我认为doctests更难为集成测试这样的事情写作。但是，正如您在python和Django上看到的那样 - 他们广泛使用doctests，这会产生更易理解的文档和教程。
这一切都取决于你的项目。没有“正确”的方法来测试。
另外，我建议您查看Code Complete 2本书，因为您可能会发现单元测试不是确保您的软件无故障的最佳方法。
答案 2 :(得分：5)
Python标准库中有一个具体的例子，说服我单凭doctests并不总是足够，即decimal模块。它有超过60000个单独的测试用例（在Lib / test / decimaltestdata中）;如果所有这些都被重写为doctests，十进制模块确实会变得非常笨拙。测试数量可能会减少，同时仍能提供良好的覆盖率，但许多数值算法都非常复杂，以至于您需要大量的单独测试来覆盖所有可能的分支组合。
答案 3 :(得分：2)
doctests非常适合某些用途
单元测试在不同情况下更好：
换句话说，至少对我自己来说，当你专注于解释你正在做的事情（文档，还有设计阶段）时，doctests很棒，但当你打算将测试用作安全带时，更多的负担重构或代码覆盖。
答案 4 :(得分：0)
可能使用doctests实现完整的单元测试套件。但是，doctests有点受限，通常最好保留简单的文档示例，并使用更强大的单元测试框架（例如unittest）进行真实详细的单元测试。
unittest的另一个优点是来自使用JUnit，NUnit或类似的不同开发环境的人会熟悉测试框架。 doctest模块略有不同。
答案 5 :(得分：0)
我认为这是考虑doctests的错误方法。 Doctests是文档。它们补充了常规单元测试。 将doctests视为恰好经过测试的文档示例。 doctests应该用于向人类用户说明该功能。单元测试应该测试所有代码，甚至是极端情况。如果您为角落案例或几十个doctests添加doctests，那么这将使您的文档字符串难以阅读。