编辑：切换到一个更好的示例，并阐明了为什么这是一个真正的问题。

我想用Python编写在断言失败时继续执行的单元测试，这样我就可以在一个测试中看到多个失败。例如：

class Car(object):
  def __init__(self, make, model):
    self.make = make
    self.model = make  # Copy and paste error: should be model.
    self.has_seats = True
    self.wheel_count = 3  # Typo: should be 4.

class CarTest(unittest.TestCase):
  def test_init(self):
    make = "Ford"
    model = "Model T"
    car = Car(make=make, model=model)
    self.assertEqual(car.make, make)
    self.assertEqual(car.model, model)  # Failure!
    self.assertTrue(car.has_seats)
    self.assertEqual(car.wheel_count, 4)  # Failure!

在这里，测试的目的是确保Car’s__init__正确设置其字段。我可以将其分解为四个方法（这通常是个好主意），但是在这种情况下，我认为将其保留为测试单个概念的单个方法（“对象已正确初始化”）更容易理解。

如果我们认为最好不要破坏该方法，那么我有一个新问题：我无法一次看到所有错误。当我修复model错误并重新运行测试时，wheel_count错误就会出现。当我第一次运行测试时，这将节省我看到两个错误的时间。

为了进行比较，Google的C
++单元测试框架区分了非致命EXPECT_*断言和致命ASSERT_*断言：

断言成对出现，测试相同的事物，但对当前函数有不同的影响。ASSERT_ 版本在失败时会产生致命错误，并中止当前功能。EXPECT_
版本会产生非致命故障，不会导致当前功能终止。通常首选EXPECT_
，因为它们允许在测试中报告多个故障。但是，如果在所声明的断言失败后继续执行没有意义，则应使用ASSERT_ 。

有没有一种方法可以EXPECT_*在Python的行为unittest？如果不在中unittest，那么是否存在另一个支持此行为的Python单元测试框架？

顺便说一句，我很好奇非致命性断言可能会带来多少实际测试，因此我看了一些代码示例（于2014-08-19编辑，使用searchcode代替了Google
Code Search，RIP）。从第一页随机选择的10个结果中，所有包含的测试都在同一测试方法中做出了多个独立的断言。所有人将从非致命的断言中受益。