相关疑难解决方法(0)

当断言失败时继续Python的unittest

编辑:切换到一个更好的例子,并澄清为什么这是一个真正的问题.

我想在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!
Run Code Online (Sandbox Code Playgroud)

在这里,测试的目的是确保Car __init__正确设置其字段.我可以将它分解为四种方法(这通常是一个好主意),但在这种情况下,我认为将它作为测试单个概念的单个方法("对象被正确初始化")更具可读性.

如果我们假设这里最好不分解方法,那么我有一个新问题:我无法立即看到所有错误.当我修复model错误并重新运行测试时,会wheel_count出现错误.当我第一次运行测试时,它可以节省我看到两个错误的时间.

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

断言成对出现,测试相同的东西但对当前函数有不同的影响.ASSERT_*版本在失败时会生成致命的故障,并中止当前的功能.EXPECT_*版本生成非致命故障,不会中止当前功能.通常EXPECT_*是首选,因为它们允许在测试中报告多个失败.但是,如果在有问题的断言失败时继续没有意义,则应使用ASSERT_*.

有没有办法EXPECT_*在Python中获得类似行为unittest?如果没有 …

python unit-testing

74
推荐指数
7
解决办法
3万
查看次数

为什么单元测试只测试一件事?

什么是良好的单元测试?说测试应该测试一件事.这有什么好处?

写一些更大的测试来测试更大的代码块会不会更好?无论如何,调查测试失败很困难,我从小测试中看不到它的帮助.

编辑:单词单位并不重要.让我们说我认为单位更大一些.这不是问题所在.真正的问题是为什么对所有方法进行测试或更多测试,因为很少有涵盖许多方法的测试更简单.

一个例子:列表类.我为什么要单独进行添加和删除测试?首先添加的一个测试然后删除声音更简单.

unit-testing

58
推荐指数
6
解决办法
9328
查看次数

在单元测试中有多个断言是不好的做法吗?

在单元测试中有多个断言是不好的做法吗?有关系吗?

unit-testing assert

43
推荐指数
4
解决办法
2万
查看次数

在一次测试中检查几个不同的示例输入?

假设我想编写一个用正则表达式验证电子邮件地址的函数.我写了一个小测试来检查我的功能并编写实际的功能.让它通过.

但是,我可以提出一些不同的方法来测试相同的功能(test@test.com; test234@test.com; test.test.com等).

我是否将所需的所有咒语都用几个ASSERTS进行相同的单一测试,或者为我能想到的每一件事写一个新的测试?

谢谢!

tdd nunit unit-testing

23
推荐指数
2
解决办法
3987
查看次数

标签 统计

unit-testing ×4

assert ×1

nunit ×1

python ×1

tdd ×1