单元测试组合的数量惊人

Question

我是单元测试的新手（现在是现实世界中的应届毕业生）。我对编写测试需要多长时间感到困惑。

让我们举一个基本的例子。我写了一个像这样的函数：

def add(a, b)
    return a + b

我想测试它的整数和无限精度浮点数的输入。例如，测试用例名称可以是test_add_ Negative_integer_to_Negative_integer。

假设
在边界处测试边缘情况可以代表所有其他情况。
边缘/边界
数值类型 = {整数、浮点}
数值 = {负数、零、正数}
测试用例数量
与重复的组合（假设参数顺序并不重要）。

C(3 + 2 - 1, 2) * C(2 + 2 - 1, 1) = 18 个测试用例以满足假设条件。
将另一个值添加到数值类型集会产生36 个不同的测试用例。

难道我做错了什么？

Answer 1

您的测试目标是什么？

它是否详尽地涵盖了所有可能的输入？正如您所列出的，需要 18 个测试用例才能完全覆盖所有组合，但这些组合是否必要？

风险分析与确定代码测试的详尽程度密切相关。与该方法存在缺陷相关的技术风险和业务风险是什么？如果这是一个严重风险，那么所有 18 种组合可能都是必要的。此外，某种随机测试也非常有帮助。

IMO，对于单元测试，我发现覆盖率是一个很好的指导指标，它提供了高度的置信度，同时避免了所有组合。如果您使用覆盖率作为目标，那么此方法只需要一个单元测试。

如果这是一个关键功能，并且需要所有组合，我会推荐数据驱动的方法。这是指定所有 18 个测试用例并使用相同代码驱动每个测试的干净方法。它解决了必须单独编写 18 个test_this_and_this.

使用鼻子参数化：

@parameterized([
    (1, -1.0, 0),
    (2, 3, 8),
    (1, 9, 1),
    (0, 9, 0),
])
def test_add(first, second, expected):
    assert_equal(add(first, second), expected)

数据驱动测试也是一个很棒的组织工具。如果您发现自己与非技术测试人员一起工作，那么能够创建一个测试驱动程序，然后让非技术人员设计一个包含所有相关业务相关测试用例的 CSV，并将其作为数据驱动的输入提供，这是非常强大的测试。