Question

假设您在业务层中有一个类的方法check（），它对该类的实例进行一些验证。如果该类的属性a具有特定值，则检查具有形式，属性b需要具有某个其他值（即确定b）。例如，该方法可以在内部使用包含a和b的所有有效组合的映射：

public bool check() {
   if (mapOfValidCombos.get(a)!=b)
        return false;
   return true;
}

或者它可以在外部csv文件中查找它们，或者它可以包含if语句列表：

public bool check() {
    if (a==1) and (b!=5) then return false;
    if (a==2) and (b!=3) then return false;
    return true;
}

现在，如果您想对该方法进行单元测试。您应该实施哪些测试用例：

您可以测试a和b的所有有效组合，以及无效组合（假设a和b是可枚举的类型）
您只能为该方法的每个路径创建一个测试用例（例如，一个用于有效组合，一个用于无效组合）

方法2导致较少的单元测试用例（因此对它们的维护工作量较少）。但是，在哪里是实际测试该方法从业务角度进行正确检查的正确位置（例如，如果有效组合的映射中包含正确的值？）。

如果你选择第1号方法，你应该添加额外的测试用例，如果你改变实现，可以说map base to if语句，因为你获得了更多的方法执行路径？

编辑：我考虑的是这些测试会为我们的测试套件增加多少价值。让我们说如果去check（）方法的基于地图的实现，有什么用途将地图的内容复制到我的测试用例中。关于hidro提示使用paraterized测试。他们仍然需要从某个地方获取他们的参数（并且很可能不是在check（）的实现中），因此这些值在某种程度上是重复的。我更多地考虑实际值的测试和检查方法的完整性是由QA或业务部门在验收测试中完成的，其中我的单元测试只是检查我的代码的执行路径而不一定允许值的所有组合。有什么想法吗？

Answer 1

我的经验法则是：

尽可能尝试每个测试方法只有一个assert。如果要一起评估，只能使用多个assert。
使用单个assert编写测试，直到覆盖所有执行路径，这意味着多个测试可能共享相同的assert输出，但具有不同的输入值，这些都会导致相同的期望。

现在，如果你开始在测试课中看到很多重复，那就不用了。

＆＃39;参数化＆＃39;你的考试。我不确定您使用的语言，但其中许多语言支持参数化测试，例如PHPUnit's @dataProvider或Java's JunitParams，其中包含一个＆＃39;表格＆＃39;测试规范，执行相同的测试代码（相同的assert）。
避免编写实用程序方法或类来重用测试代码，从长远来看，它更具反模式而不是有用。

确定方法的最实用数量的测试用例

1 个答案: