我一直听到人们说测试应该如何简单,可维护,直接,但是在单元测试中代码可重用性会发生什么?

让我们举个例子:

def test_some_1():
    ...some code

def test_some_2():
    ...code repeated from test_some_1

将两个测试中的重复代码封装在一个包含必要断言的函数中不是最好的吗?

我和一些程序员争论过,他们不同意,他们说测试应该是愚蠢的,代码的可重用性在这里不好。这样做的原因是因为它在django控制台中并不是很清楚断言实际上失败了,因为断言在函数中,尽管我不同意,因为用鼻子使用它会给你测试的名称和回溯,尽管这些人再次不同意,指出一个测试可以在没有鼻子的情况下单独调用(因此你看不到所有的细节)。

你们怎么想?

  • 在单元测试中使用代码可重用性好吗?
  • 如果可重用性可以/必须使用,那么如何克服关于针指向断言的其他问题?
有帮助吗?

解决方案

代码质量的最重要因素,如清晰度和可读性,对于测试代码也很重要。如果代码重复使其更易于阅读,那么无论您正在编写的是测试代码,您都应该这样做,反之亦然。

例如,在我写的一个包中,我有一个函数:

def _test_vector(self, a, b, c):
    # test the function with parameter values a, b, c
    # several asserts here to verify output of function tested

这可以写出所有的测试向量,比如:

def test_vector1(self):
    self._test_vector(a=42, b=5, c="blah)

IMO提高了清晰度,因为单个测试只包含特定于该测试的信息。

精确定位断言应该总是很容易的。甚至 unittest 会给你一个回溯,如果你的测试设置没有指向一个特定的断言,你将很难调试任何测试失败,并且肯定应该切换到明智的事情。

其他提示

在你的同龄人说,你应该写下你的测试愚蠢。有几个原因,最重要的是您希望避免在测试中的复杂逻辑。如果您确实编写了测试“Smart”,它们往往包含与您正在尝试测试的代码相同或相似的逻辑。这意味着您的风险在两个地方产生同样的错误,并将错过您要查找的错误。

另一个原因是您希望您的测试充当您尝试测试的代码的文档。如果测试具有通过许多函数和逻辑的复杂的执行路径,则不会易于理解。在世界上最好的,您将看到生产代码是如何通过在测试中瞥见的原因。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top