我是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 unittest文档之间的编辑： 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]可帮助您确定问题所在：导致故障 通过不正确的结果 - 5你预期的地方6.导致错误 不正确的代码 - 例如，由错误的函数引起的TypeError 调用
正在考虑该问题的其他标题：
“为什么单元测试会出现'失败'和'错误'的情况？”
或
“'失败'和'错误'之间的哲学差异是什么？
或
“在TDD中，是否所有”失败的测试“都应该写成”失败“或者”错误“可以接受”
仍然试图准确地确定我在这里要求的内容，而没有得到像“一个是断言错误而另一个不是”的简单答案，我很乐意将其投票。
答案 0 :(得分：1)
抛出异常是指示失败的一种方法。这意味着测试的前提条件之一未得到满足。询问“这个调用是否未能引发异常”通常并不常见 - 这是一个我们不得不问所有代码的问题。
发现“这个名义上有效的输入导致抛出异常”的错误表明测试套件中存在错误 - 某些类别的输入未被覆盖。导致异常抛出的输入类通常需要稍微专门的规则来预测输出应该是什么，所以在测试新发现的bug时几乎总是有文档价值作为缺乏覆盖bug的修复
这是一种啰嗦的方式，说是的，你写的测试测试了两件事。但它测试的东西之一是我们不应该明确测试的东西，因为它没有意思。镗孔测试是不好的测试。