Question

我一直听到有人说测试应该如何简单，可维护，直截了当，但是在单元测试中代码重用性会发生什么？

让我们举个例子：

def test_some_1():
    ...some code

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

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

我和一些程序员争论过这个并且他们不同意，他们说测试应该是愚蠢的，代码重用性在这里并不好。这样做的原因是因为在django控制台中断言实际上失败了并不是很清楚，因为断言是在函数中，虽然我不同意，因为使用它与鼻子会给你测试的名称和追溯，虽然这些家伙再次不同意，说明可以在没有鼻子的情况下单独调用测试（因此你无法看到所有这些细节）。

你们有什么想法？

在单元测试中使用代码重用性是否合适？
如果可以/必须使用可重用性，那么如何克服针对断言的其他问题呢？

Answer 1

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

例如，在我写的一个包中，我有一个函数：

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也会给你追溯，如果你的测试设置没有指向特定的断言，你将很难调试任何测试失败，并且肯定会切换到合理的东西。

Answer 2

正如你的同伴所说，你应该把你的测试写得愚蠢。这有几个原因，最重要的原因是您希望避免测试中的复杂逻辑。如果您确实将测试编写为“智能”，则它们往往包含与您尝试测试的代码相同或类似的逻辑。这意味着你冒着在两个地方犯同样错误的风险，并且会错过你想要找到的错误。

另一个原因是您希望测试充当您要测试的代码的文档。如果测试通过许多函数和逻辑具有复杂的执行路径，那么它将不那么容易理解。在最好的世界中，您可以通过浏览测试来了解生产代码的工作方式。

单元测试中的代码可重用性？

2 个答案: