为什么 unittest 中的断言使用 TestCase.assertEqual 而不是 assert 关键字？答案

【问题标题】：Why do assertions in unittest use TestCase.assertEqual not the assert keyword?为什么 unittest 中的断言使用 TestCase.assertEqual 而不是 assert 关键字？
【发布时间】：2011-06-15 16:37:22
【问题描述】：

Python 的内置 unittest 模块使用 TestCase.assert* 方法进行断言：

class FooTest(TestCase):
    def test_foo(self):
        self.assertEqual(1,1)
        self.assertNotEqual(1,2)
        self.assertTrue(True)

我通常使用 nose 或 py.test 等测试运行程序，它们允许在进行断言时使用内置的 assert 关键字：

assert 1 == 1
assert 1 != 2
assert True

unittest 的TestCase.assert* 方法的动机是什么？这与使用内置 assert 关键字断言的优缺点是什么？是否有理由支持 unittest 的语法？

【问题讨论】：

这是测试框架中的一个常见习语，与语言无关。尽管如此，这是一个很好的问题。
重复What are the advantages or difference in “assert False” and “self.assertFalse”

标签： python unit-testing

【解决方案1】：

assert 关键字的问题在于，当 Python 在“优化”模式下运行时（使用 -O 参数或 @987654323 @ 环境变量集。）如果测试使用assert，那么使用-O 进行测试将是不可能的。

此外，使用 assert 方法可以轻松报告所涉及的实际值是什么，而无需深入研究堆栈和源代码并找出它们应该是什么（我相信这是技术nose 和py.test 用于此。）

【讨论】：

如果您正在测试代码，您可能没有在优化模式下运行它。
+1 虽然我怀疑有人会使用-O 开关运行他们的单元测试。
如果您没有以与在生产环境中运行代码相同的方式测试代码，那么您就没有正确执行。测试框架不是决定你不应该在生产中使用 -O 的东西（尽管你可能不应该。）
谢谢@Thomas。如果我理解正确：虽然nose 和py.test 提供了unittest 的替代断言，但它们的代价是妥协-O 并依赖于更复杂的报告实现。
JBernardo：非常不同意——曾经有代码在 Debug 中运行良好，但在 Release 中表现得很好（反之亦然）？它可能会发生，在大多数情况下，您应该在尽可能接近最终的环境中进行测试。

【解决方案2】：

我没有看到具体的设计决策。看着unittest docs 它说那个

将调用特定类型的相等函数以生成更有用的默认错误消息

所以我会说这是一个帮助产生更有意义的错误等的实施决策。

【讨论】：

【解决方案3】：

这种方法的主要优势在于提供了几个通常执行的内置测试，这样就不必一遍又一遍地编写它们。此外，assertRaises 允许您通过引发异常来自定义断言的确切行为。

【讨论】：

【解决方案4】：

unittest 语法是针对 Python 实现 assert 的一个弱点的解决方法。 Pytest 有另一种断言重写的解决方法，它以更好的方式在很大程度上解决了这个问题。与assertFoo 风格的断言相比，它在为断言提供漂亮的错误消息方面也更好。

使用 pytest，过上更快乐、更有成效的生活：P

【讨论】：

能否详细说明“弱点”？
断言不会收集有关失败原因的任何信息。就像assert a == b 不会显示a 或b 的值，或者它是一个比较。只是堆栈跟踪。