Python-doctest与unittest [关闭]

问题:Python-doctest与unittest [关闭]

我正在尝试使用Python进行单元测试,我想知道是否有人可以解释doctest和unittest的优缺点。

您将分别使用什么条件?

I’m trying to get started with unit testing in Python and I was wondering if someone could explain the advantages and disadvantages of doctest and unittest.

What conditions would you use each for?


回答 0

两者都很有价值。我用doctest和鼻子代替了unittest。我将doctest用于测试给出了实际用作文档的用法示例的情况。通常,我不会对这些测试进行全面的测试,仅是为了提供信息。我实际上是在反向使用doctest:不是根据doctest来测试我的代码是否正确,而是根据代码来检查我的文档是否正确。

原因是我发现全面的doctest会使您的文档过于混乱,因此您要么会得到不可用的文档字符串,要么会得到不完整的测试。

对于实际测试代码,目标是彻底测试每种情况,而不是通过示例来说明这样做是什么,我认为这是一个不同的目标,我认为其他框架可以更好地实现。

Both are valuable. I use both doctest and nose taking the place of unittest. I use doctest for cases where the test is giving an example of usage that is actually useful as documentation. Generally I don’t make these tests comprehensive, aiming solely for informative. I’m effectively using doctest in reverse: not to test my code is correct based on my doctest, but to check that my documentation is correct based on the code.

The reason is that I find comprehensive doctests will clutter your documentation far too much, so you will either end up with either unusable docstrings, or incomplete testing.

For actually testing the code, the goal is to thoroughly test every case, rather than illustrate what is does by example, which is a different goal which I think is better met by other frameworks.


回答 1

我几乎只使用unittest。

偶尔,我会在doctest中使用一些东西。

95%的测试用例是单元测试。

为什么?我喜欢使文档字符串的长度更短,更准确。有时,测试用例有助于澄清文档字符串。大多数情况下,应用程序的测试用例对于文档字符串来说太长了。

I use unittest almost exclusively.

Once in a while, I’ll put some stuff in a docstring that’s usable by doctest.

95% of the test cases are unittest.

Why? I like keeping docstrings somewhat shorter and more to the point. Sometimes test cases help clarify a docstring. Most of the time, the application’s test cases are too long for a docstring.


回答 2

doctesting的另一个优点是,您可以确保代码执行的工作与文档中所说的一样。一段时间后,软件更改可能会使您的文档和代码执行不同的操作。:-)

Another advantage of doctesting is that you get to make sure your code does what your documentation says it does. After a while, software changes can make your documentation and code do different things. :-)


回答 3

我是一名生物信息学家,我编写的大多数代码都是“一次,一项任务”脚本,这些代码将只运行一次或两次,并执行一个特定的任务。

在这种情况下,编写大型单元测试可能会过分杀人,而doctest是一个有用的折衷方案。它们的编写速度更快,并且由于它们通常包含在代码中,因此它们可以始终关注代码的行为方式,而不必打开另一个文件。这在编写小脚本时很有用。

另外,当您必须将脚本传递给不是编程专家的研究人员时,doctest也很有用。有些人很难理解单元测试的结构。另一方面,doctests是用法的简单示例,因此人们可以将其复制并粘贴以了解如何使用它们。

因此,请恢复我的答案:doctest在必须编写小型脚本以及必须将其传递或展示给非计算机科学家的研究人员时很有用。

I work as a bioinformatician, and most of the code I write is “one time, one task” scripts, code that will be run only once or twice and that execute a single specific task.

In this situation, writing big unittests may be overkill, and doctests are an useful compromise. They are quicker to write, and since they are usually incorporated in the code, they allow to always keep an eye on how the code should behave, without having to have another file open. That’s useful when writing small script.

Also, doctests are useful when you have to pass your script to a researcher that is not expert in programming. Some people find it very difficult to understand how unittests are structured; on the other hand, doctests are simple examples of usage, so people can just copy and paste them to see how to use them.

So, to resume my answer: doctests are useful when you have to write small scripts, and when you have to pass them or show them to researchers that are not computer scientists.


回答 4

如果您刚开始使用单元测试的想法,那么我将以doctest它为起点,因为它非常易于使用。它自然也提供了一定程度的文档。并进行更全面的测试doctest,您可以将测试放在一个外部文件中,以免使文档混乱。

我建议unittest如果您来自使用过JUnit或类似工具的背景,那么您希望能够以与其他地方相同的方式编写单元测试。

If you’re just getting started with the idea of unit testing, I would start with doctest because it is so simple to use. It also naturally provides some level of documentation. And for more comprehensive testing with doctest, you can place tests in an external file so it doesn’t clutter up your documentation.

I would suggest unittest if you’re coming from a background of having used JUnit or something similar, where you want to be able to write unit tests in generally the same way as you have been elsewhere.


回答 5

我专门使用unittest;我认为doctest会使主模块过于混乱。这可能与编写全面的测试有关。

I use unittest exclusively; I think doctest clutters up the main module too much. This probably has to do with writing thorough tests.


回答 6

同时使用这是一个有效且相当简单的选择。该doctest模块提供了DoctTestSuiteDocFileSuite方法,分别从模块或文件创建与unittest兼容的测试套件。

因此,我会同时使用doctest和通常使用doctest的简单测试,这些测试需要的功能很少或不需要设置(参数的简单类型)。实际上,我认为一些doctest测试有助于记录功能,而不是削弱功能。

但是对于更复杂的案例和更全面的测试案例,我使用unittest来提供更多的控制和灵活性。

Using both is a valid and rather simple option. The doctest module provides the DoctTestSuite and DocFileSuite methods which create a unittest-compatible testsuite from a module or file, respectively.

So I use both and typically use doctest for simple tests with functions that require little or no setup (simple types for arguments). I actually think a few doctest tests help document the function, rather than detract from it.

But for more complicated cases, and for a more comprehensive set of test cases, I use unittest which provides more control and flexibility.


回答 7

我不使用doctest代替unittest。尽管它们有些重叠,但这两个模块却没有相同的功能:

  • 我将其unittest用作单元测试框架,这意味着它可以帮助我快速确定任何修改对其余代码的影响。

  • doctest保证注释(即文档字符串)仍然与当前代码版本相关。

我从中获得了广泛记录的测试驱动开发的好处unittestdoctest解决了过时的注释误导了代码维护的更为微妙的危险。

I don’t use doctest as a replacement for unittest. Although they overlap a bit, the two modules don’t have the same function:

  • I use unittest as a unit testing framework, meaning it helps me determine quickly the impact of any modification on the rest of the code.

  • I use doctest as a guarantee that comments (namely docstrings) are still relevant to current version of the code.

The widely documented benefits of test driven development I get from unittest. doctest solves the far more subtle danger of having outdated comments misleading the maintenance of the code.


回答 8

我几乎从不使用doctests。我希望我的代码能够自我记录,并且文档字符串将文档提供给用户。IMO向模块添加了数百行测试,使文档字符串的可读性大大降低。我还发现单元测试更容易在需要时进行修改。

I almost never use doctests. I want my code to be self documenting, and the docstrings provide the documentation to the user. IMO adding hundreds of lines of tests to a module makes the docstrings far less readable. I also find unit tests easier to modify when needed.


回答 9

Doctest有时会导致错误的结果。特别是当输出包含转义序列时。例如

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

也不会检查输出的类型。它只是比较输出字符串。例如,它已经使某种类型的有理数,如果它是一个整数,则它的打印效果类似于整数。然后假设您具有返回有理数的函数。因此,doctest不会区分输出是有理整数还是整数。

Doctest can some times lead to wrong result. Especially when output contains escape sequences. For example

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

gives

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

Also doesn’t check the type of the output. It just compares the output strings. For example it have made some type rational which prints just like integer if it is a whole number. Then suppose you have function which return rational. So, a doctest won’t differentiate if the output is rational whole number or a integer number.


回答 10

我更喜欢基于发现的系统(“ nose”和“ py.test”,目前使用前者)。

当测试也可以作为文档时,doctest很好,否则它们会使代码过于混乱。

I prefer the discovery based systems (“nose” and “py.test”, using the former currently).

doctest is nice when the test is also good as a documentation, otherwise they tend to clutter the code too much.