unit-testing - 在维护测试套件时，所有 'errors' 最终都应该变成 'failures' 吗？

Question

我是 python unittest 的用户，但这跨越了所有语言。

Senario:我发现了“functionBeingTested”中的一个缺陷。
缺陷是在有效输入时代码会崩溃(抛出异常)

在写测试用例的时候，我可以很简单的:

def testThis(self):
    self.assertEqual( functionBeingTested("valid input"), "expected output")

在 TDD 术语中，这应该是“失败”，但相反，它会引发异常，您会得到一个“错误”:

 Ran 1 tests with 0 failures and 1 errors

人们会假设您想要:

 Ran 1 tests with 1 failures and 0 errors

这个有解决方案Python unittest: Reporting Exception as Failure

这里有类似的讨论:pass a unit test if an exception isn't thrown

但这不是问题。

问题是“维护测试套件的最佳实践”

在纯测试驱动开发中编写“错误测试用例”[如果存在这样的事情]在哲学上是否可以接受，或者应该编写此单元测试以捕获异常并引发断言错误以证明“失败”而不是“错误”。

更多阅读未能阐明这个问题: http://www.computer.org/portal/web/swebok/html/ch5#Ref1.1.2
“软件工程术语的 IEEE 标准词汇表”(google it)

并查看 Python 2 和 Python 3 单元测试文档之间的编辑: http://docs.python.org/2/library/unittest.html#organizing-test-code http://docs.python.org/3/library/unittest.html#organizing-test-code

似乎在 Python 3 中省略了这个短语:

[error] helps you identify where the problem is: failures are caused by incorrect results - a 5 where you expected a 6. Errors are caused by incorrect code - e.g., a TypeError caused by an incorrect function call.

---

正在考虑此问题的其他标题:
“为什么单元测试会出现‘失败’和‘错误’的情况？”
或者
"'失败'和'错误'之间的哲学区别是什么
或者
“在 TDD 中，所有“失败的测试”都应该写成抛出‘失败’还是‘错误’是可以接受的”

仍在尝试准确确定我在这里要问的内容，而没有得到像“一个是断言错误而另一个不是”这样的简单答案，我很乐意投反对票。

Answer 1

抛出异常是指示失败的一种方式。这意味着不满足测试的先决条件之一。问“这个调用是否没有抛出异常”通常并不有趣——这是一个我们不得不问所有代码的问题。

“这个名义上有效的输入导致异常被抛出”的错误被发现表明测试套件中存在错误——某些输入类别没有被覆盖。导致异常被抛出的输入类通常需要关于预期输出应该是什么的稍微专门的规则，因此将新发现的错误的测试措辞为缺乏覆盖错误的修复几乎总是具有文献值(value).

这是一种冗长的说法，是的，您编写的测试测试了两件事。但是它测试的其中一件事是我们不应该明确测试的事情，因为它并不有趣。无聊的测试是糟糕的测试。