【问题标题】:Should test cases be written for methods that wrap third party code?是否应该为包装第三方代码的方法编写测试用例?
【发布时间】:2015-04-22 11:46:58
【问题描述】:

在我的应用程序中,我有验证 CIDR 地址的方法。它所做的只是环绕 ipv4 validate_cidr 方法:

def isValidCIDR(self, cidr):
    return iptools.ipv4.validate_cidr(cidr)

我个人不喜欢它。我宁愿把验证检查放在main()

我这样做的唯一原因是因为我编写了测试来验证 CIDR 地址:

def test_input_for_valid_cidr_format(self):
    cidr = '192.168.2.4/24'
    self.assertTrue(self.scanner.isValidCIDR(cidr))

有必要写这样的测试吗?

【问题讨论】:

  • Unit test wrapper objects? 的可能重复项
  • 一个更好的问题是为什么isValidCIDR 是一个实例方法,因为self 没有在主体中使用。包装器似乎没有理由首先存在。
  • @chepner 它是类的一部分,我没有包含任何其他代码或有关系统的详细信息,因为这样做没有任何目的。
  • 那么您可以考虑将其设为@classmethod

标签: python unit-testing tdd


【解决方案1】:

另一个答案说:

进行测试的主要优点是可以让您退出 稍后实施,并确保它仍然可以作为 预计。

这正是我为包装代码编写测试用例的确切原因。在某些时候,我可能会想要针对包装代码的更新版本测试我的代码。如果我自己编写一个测试,我会知道包装的代码是否仍然按我的用例的预期执行。

我还会编写测试以确保在调用包装代码时不会犯愚蠢的错误(我犯了很多这样的错误)。即,以错误的顺序获取参数:

def foo(x, y):
    # Wrapped function.
    ...

def call_foo(x, y):
    # My wrapper
    return foo(y, x)

【讨论】:

  • 我想说很多你担心的事情应该通过包本身的测试或正常的测试来处理,因此我个人认为这不会增加价值。跨度>
  • 我同意这是一个偏好问题。出于你所说的原因,我也走了另一条路。至于我,我通常只是更舒服地编写测试。这对我来说不是一个高优先级,但无论如何我都会这样做。
  • +1 此技术在“直接使用第三方库测试包装器”下的 here 进行了说明
【解决方案2】:

进行测试的主要优点是允许您稍后切换实现并确保它仍能按预期工作。

就我个人而言,除非我在方法中执行一些逻辑,或者正在认真考虑切换实现,或者担心某些边缘情况下的实现,否则我不会围绕库函数测试瘦包装器。我认为它没有为付出的努力提供足够的价值。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2014-10-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-10-19
    • 1970-01-01
    相关资源
    最近更新 更多