失败的unittest测试用例 [英] Failing unittest Test cases

问题描述

有一种关于在测试套件中提供测试用例的方法的一些讨论，但是不能。其中一条规则是

测试套件应该在每次检查时都可以运行并保持沉默。最近

有一个测试的签到_should_工作但是没有。

讨论了解这些测试的方法（因为应该捕获创建测试的b / b
）而不会打扰

开发流程。


以下代码演示了一个装饰器，它可能用于支持这个过程的
。任何评论，添加，删除？


来自unittest import TestCase

class BrokenTest（TestCase.failureException）：

def __repr __（自我）：

返回''％s：％s：％s现在可以使用''％（

（self .__ class __.__ name __，）+ self.args）


def broken_test_XXX（原因，*例外）：

''''''表示应该成功的测试用例不成功。

如果异常导致测试失败，则在args''''中添加异常类型。

def包装器（test_method）：

def替换（* args，* * kwargs）：

试试：

test_method（* args，** kwargs）

除了异常+（TestCase.failureException，）：

通过

否则：

提高BrokenTest（test_method .__ name__，原因）

replacement .__ doc__ = test_method .__ doc__

替换.__ name__ =''XXX_''+ test_method .__ name__

replacement.todo = reason

返回替换
返回包装器

您将使用它：

class MyTestCase（unittest.TestCase）：

def test_one（自我）：...

def test_two（个体经营）：...

@broken_test_XXX（笨拙的还没有gsnort）

def test_three（self）：...

@broken_test_XXX（" Using list as dictionary"，TypeError）

def test_four（self）：.. 。


它还会指出测试何时开始成功。


--Scott David Daniels
sc *********** @ acm.org

There has been a bit of discussion about a way of providing test cases
in a test suite that _should_ work but don''t. One of the rules has been
the test suite should be runnable and silent at every checkin. Recently
there was a checkin of a test that _should_ work but doesn''t. The
discussion got around to means of indicating such tests (because the
effort of creating a test should be captured) without disturbing the
development flow.

The following code demonstrates a decorator that might be used to
aid this process. Any comments, additions, deletions?

from unittest import TestCase
class BrokenTest(TestCase.failureException):
def __repr__(self):
return ''%s: %s: %s works now'' % (
(self.__class__.__name__,) + self.args)

def broken_test_XXX(reason, *exceptions):
''''''Indicates unsuccessful test cases that should succeed.
If an exception kills the test, add exception type(s) in args''''''
def wrapper(test_method):
def replacement(*args, **kwargs):
try:
test_method(*args, **kwargs)
except exceptions + (TestCase.failureException,):
pass
else:
raise BrokenTest(test_method.__name__, reason)
replacement.__doc__ = test_method.__doc__
replacement.__name__ = ''XXX_'' + test_method.__name__
replacement.todo = reason
return replacement
return wrapper
You''d use it like:
class MyTestCase(unittest.TestCase):
def test_one(self): ...
def test_two(self): ...
@broken_test_XXX("The thrumble doesn''t yet gsnort")
def test_three(self): ...
@broken_test_XXX("Using list as dictionary", TypeError)
def test_four(self): ...

It would also point out when the test started succeeding.

--Scott David Daniels
sc***********@acm.org

推荐答案

2006年1月9日，Scott David Daniels写道：

On 9 January 2006, Scott David Daniels wrote:

关于在测试中提供测试用例的方法有一些讨论_should_工作的套房但不是。其中一条规则是测试套件应该在每次检查时都可以运行并保持静音。最近
有一个测试的签到_should_工作，但没有。
讨论了解了这些测试的方法（因为应该捕获创建测试的努力），而不会影响开发流程。

以下代码演示了一个可能用于帮助此过程的装饰器。任何评论，添加，删除？

There has been a bit of discussion about a way of providing test cases
in a test suite that _should_ work but don''t. One of the rules has been
the test suite should be runnable and silent at every checkin. Recently
there was a checkin of a test that _should_ work but doesn''t. The
discussion got around to means of indicating such tests (because the
effort of creating a test should be captured) without disturbing the
development flow.

The following code demonstrates a decorator that might be used to
aid this process. Any comments, additions, deletions?

有趣的想法。我一直在为我的测试功能添加''f''

还没有工作，所以他们根本就没有跑。然后，当我有时间

添加新功能时，我会在测试套件中找到''ftest''。


- Eric

Interesting idea. I have been prepending ''f'' to my test functions that
don''t yet work, so they simply don''t run at all. Then when I have time
to add new functionality, I grep for ''ftest'' in the test suite.

- Eric

Scott David Daniels写道：

Scott David Daniels wrote:

关于在测试套件中提供测试用例的方法有一些讨论，但这些测试套件可以工作但是没有'' T。其中一条规则是测试套件应该在每次检查时都可以运行并保持静音。最近
有一个测试的签到_should_工作，但没有。
讨论了解了这些测试的方法（因为应该捕获创建测试的努力），而不会干扰开发流程。

There has been a bit of discussion about a way of providing test cases
in a test suite that _should_ work but don''t. One of the rules has been
the test suite should be runnable and silent at every checkin. Recently
there was a checkin of a test that _should_ work but doesn''t. The
discussion got around to means of indicating such tests (because the
effort of creating a test should be captured) without disturbing the
development flow.

只有一种情况我可以想到我会在哪里使用它，

，这就是某些底层库有bug的情况。我会

添加一个测试，当bug出现时成功，并且当bug不存在时失败，即它被修复。这样，当新版本的库不再包含

错误时，您会自动收到通知

，因此您知道可以删除该错误的解决方法。然而，

我从来没有使用装饰器或任何特别的东西，因为我从来没有感觉到需要它，这样的常规测试用例对我也有用：


class SomeThirdPartyLibraryTest（unittest.TestCase）：

def testThirdPartyLibraryCannotComputeSquareOfZero（sel f）：

self.assertEqual（-1， tplibrary.square（0），

''他们最终修复了tplibrary.square中的那个错误''）


它是否违抗了目的单元测试给他们一个简单的开关所以

程序员可以随时关闭它们吗？


干杯，弗兰克

There is just one situation that I can think of where I would use this,
and that is the case where some underlying library has a bug. I would
add a test that succeeds when the bug is present and fails when the bug
is not present, i.e. it is repaired. That way you get a notification
automatically when a new version of the library no longer contains the
bug, so you know you can remove your workarounds for that bug. However,
I''ve never used a decorator or anything special for that because I never
felt the need for it, a regular testcase like this also works for me:

class SomeThirdPartyLibraryTest(unittest.TestCase):
def testThirdPartyLibraryCannotComputeSquareOfZero(sel f):
self.assertEqual(-1, tplibrary.square(0),
''They finally fixed that bug in tplibrary.square'')

Doesn''t it defy the purpose of unittests to give them a easy switch so
that programmers can turn them off whenever they want to?

Cheers, Frank

Scott David Daniels< sc *********** @ acm.org>写道：

Scott David Daniels <sc***********@acm.org> writes:

最近有一个测试的签到_should_工作但是
没有。讨论开始指出这样的测试（因为应该捕获创建测试的努力）
而不会干扰开发流程。

Recently there was a checkin of a test that _should_ work but
doesn''t. The discussion got around to means of indicating such
tests (because the effort of creating a test should be captured)
without disturbing the development flow.

你的意思是不应该工作，但是吗？无论如何我不明白

这个问题。使用assertRaises有什么问题，如果你想要b $ b检查测试是否会引发特殊异常？

Do you mean "shouldn''t work but does"? Anyway I don''t understand
the question. What''s wrong with using assertRaises if you want to
check that a test raises a particular exception?

这篇关于失败的unittest测试用例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！