我是 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单元测试有解决方案：将异常报告为失败
还有一个类似的讨论：如果没有抛出异常，则通过单元测试
但这不是问题。
问题是“维护测试套件的最佳实践”
在纯测试驱动开发中编写“错误测试用例”[如果有这样的事情]在哲学上是否可以接受，或者是否应该编写此单元测试来捕获异常并引发断言错误以证明“失败”而不是'错误'。
更多阅读未能阐明这个问题：
http: //www.computer.org/portal/web/swebok/html/ch5#Ref1.1.2
“IEEE软件工程术语标准词汇表”（谷歌它）
并查看 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] 帮助您确定问题出在哪里：失败是由不正确的结果引起的 - 5，而您期望得到 6。错误是由不正确的代码引起的 - 例如，由不正确的函数调用引起的 TypeError。
正在考虑这个问题的其他标题：
“为什么单元测试会出现‘失败’和‘错误’案例？”
或
“'失败'和'错误'之间的哲学区别是什么
或
“在 TDD 中，是否应该编写所有“失败测试”以抛出“失败”或“错误”可接受”
仍然试图准确地确定我在这里要问的内容，而没有得到像“一个是断言错误而另一个不是”这样的简单答案，我很乐意投反对票。