unittest vs py.test？ [英] unittest vs py.test?
问题描述
我已经在
过去的几个项目中使用了标准的unittest（pyunit）模块，并且一直以为它基本上工作得很好但是只是一点点
它太复杂了。
我现在开始一个新项目，我正在考虑尝试py.test
（< a rel =nofollowhref =http://codespeak.net/py/current/doc/test.html)\"target =_ blank> http://codespeak.net/py/current/doc/test。 HTML）。从文档中看起来很酷。
有没有人使用过这两种包装并且可以给b
$解析方案
[Roy Smith]我已经在过去的几个项目中使用了标准的unittest（pyunit）模块，并且一直以为它基本上工作得很好但是只是一点点太复杂了它做了什么。
我现在正在开始一个新项目，我正在考虑尝试py.test
（ http://codespeak.net/py/current/doc/test.html) 。
文档看起来很酷。有没有人使用过两种包装并且可以进行比较评论？
我用过两者并发现py.test是毫不费力，更简洁。
对于更复杂的测试策略，py.test也是一个胜利者。生成
测试比为单元测试制定类似策略更容易编写。
py.test目前与doctest不能很好地集成;然而，这将是
可能
是下一个要添加的功能（每个holger'在PyCon的演讲）。
对于输出，unittest'的TextTestRunner在成功测试时会产生漂亮，简洁的输出
。对于失败的测试，它也不错。相比之下，
py.test
输出格式更高，体积更大 - 需要一段时间才能使用
to。 />
unittest用户必须适应unittest模块的内部结构
和
熟悉其类结构（测试夹具，测试用例，测试套件，
和测试
跑步者对象）。 py.test很好地隐藏了它的实现。
py.test是相对较新的并且还在继续发展。像
GUI测试运行器这样的支持工具正在兴起。相比之下，unittest基于经过验证的
模型，代码已经成熟。
unittest模块更新出现在不同的版本中，通常是数月或数年
分开。 py.test受到subversion的不断更新。就个人而言，我喜欢
持续更新，但如果依赖它可能会令人不安
生产代码。
雷蒙德Hettinger
Roy Smith写道：
我使用了标准的unittest（pyunit）模块在过去很少有项目，并且一直认为它基本上工作得很好，但它只是有点太复杂了。
我现在正在开始一个新项目我正在考虑尝试py.test
（ http://codespeak.net/py/current/doc/test.html）。
文档看起来很酷。有没有人使用过这两种包装并且可以进行比较评论？
你见过Grig Gheorghiu的3部分单元测试比较和py.test？
http://agiletesting.blogspot.com/200...-unittest.html
http://agiletesting.blogspot.com/200...2-doctest.html
http://agiletesting.blogspot.com/200...test-tool.html
-
Nigel Rowe
垃圾邮件发送者的痘使我写下我的地址...
rho（蜗牛）swiftdsl（停止）com（停止）au
< br>
Nigel Rowe>有哟你看过Grig Gheorghiu的3部分比较
unittest和py.test？<
非常有趣的文章，谢谢。测试看起来似乎还在开发中。
对于小函数，doctests很有用，但py.test有一些
好处。可能更好的是py.test可以设计得更好，从doctests中获取一些想法，反之亦然： - ]
在py.test中我看到几个对Python语言有用的功能
也是：
加注：
py.test.raises（NameError，" self .alist.sort（int_compare）"）
py.test.raises（ValueError，self.alist.remove，6）
（尝试可能做类似的事情）
改进的错误信息：
"当遇到失败的断言时，py.test打印出行[3-4
lines？]在包含断言的方法中，包括
失败。它还打印了失败的断言所涉及的实际值和期望值。
http://agiletesting.blogspot.com/200...test-tool.html
这样的事情可以帮助避免（仅适用于简单的情况/功能！）
首先测试框架，这样你就可以正常使用了
用于测试其他代码的Python代码。
再见，
Bearophile
I''ve used the standard unittest (pyunit) module on a few projects in the
past and have always thought it basicly worked fine but was just a little
too complicated for what it did.
I''m starting a new project now and I''m thinking of trying py.test
(http://codespeak.net/py/current/doc/test.html). It looks pretty cool from
the docs. Is there anybody out there who has used both packages and can
give a comparative review?
[Roy Smith]I''ve used the standard unittest (pyunit) module on a few projects in the
past and have always thought it basicly worked fine but was just a little
too complicated for what it did.
I''m starting a new project now and I''m thinking of trying py.test
(http://codespeak.net/py/current/doc/test.html). It looks pretty cool from
the docs. Is there anybody out there who has used both packages and can
give a comparative review?
I''ve used both and found py.test to be effortless and much less verbose.
For more complex testing strategies, py.test is also a winner. The generative
tests are easier to write than crafting a similar strategy for unittest.
py.test does not currently integrate well with doctest; however, that will
likely
be the next feature to be added (per holger''s talk at PyCon).
For output, unittest''s TextTestRunner produces good looking, succinct output
on successful tests. For failed tests, it is not bad either. In contrast,
py.test
output is more highly formatted and voluminous -- it takes a while to get used
to.
unittest users have to adapt to the internal structure of the unittest module
and
become familiar with its class structure (test fixture, test case, test suite,
and test
runner objects). py.test does a good job of hiding its implementation.
py.test is relatively new and is continuing to evolve. Support tools like a
GUI test runner are just emerging. In contrast, unittest is based on a proven
model and the code is mature.
unittest module updates come up in distinct releases, often months or years
apart. py.test is subject to constant update by subversion. Personally, I like
the continuous updates, but it could be unsettling if you''re depending on it
for production code.
Raymond Hettinger
Roy Smith wrote:
I''ve used the standard unittest (pyunit) module on a few projects in the
past and have always thought it basicly worked fine but was just a little
too complicated for what it did.
I''m starting a new project now and I''m thinking of trying py.test
(http://codespeak.net/py/current/doc/test.html). It looks pretty cool
from
the docs. Is there anybody out there who has used both packages and can
give a comparative review?
Have you seen Grig Gheorghiu''s 3 part comparison of unittest, and py.test?
http://agiletesting.blogspot.com/200...-unittest.html
http://agiletesting.blogspot.com/200...2-doctest.html
http://agiletesting.blogspot.com/200...test-tool.html
--
Nigel Rowe
A pox upon the spammers that make me write my address like..
rho (snail) swiftdsl (stop) com (stop) au
Nigel Rowe>Have you seen Grig Gheorghiu''s 3 part comparison of
unittest, and py.test?<
Very interesting articles, thank you. Testing seems something still in
quick development.
For small functions the doctests are useful, but py.test has some
advantages. Probably something even better that py.test can be
designed, taking some ideas from the doctests, or vice versa :-]
In py.test I see a couple of features useful for the Python language
too:
The raises:
py.test.raises(NameError, "self.alist.sort(int_compare)")
py.test.raises(ValueError, self.alist.remove, 6)
(A try can probably do something similar)
And the improved error messages:
"When it encounters a failed assertion, py.test prints the lines [3-4
lines?] in the method containing the assertion, up to and including the
failure. It also prints the actual and the expected values involved in
the failed assertion."
http://agiletesting.blogspot.com/200...test-tool.html
Such things can help avoid (just for simple situations/functions!)
testing frameworks in the first place, so you can use just the normal
Python code to test other code.
Bye,
Bearophile
这篇关于unittest vs py.test？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
