单元测试策略：使用黑盒的冗余答案

【问题标题】：Unit tests strategy : redundancy using Black-box单元测试策略：使用黑盒的冗余
【发布时间】：2017-01-19 13:42:39
【问题描述】：

我在设计没有冗余的黑盒单元测试时遇到问题。

这是一个例子：

class A {
   Float function operationA(int: aNumber){
        if(aNumber > 0){
            return aNumber * 10 + 5.2;
        }
        else if (aNumber < 0) {
            return aNumber * 7 - 5.2;
        }
        else {
            return aNumber * 78 + 9.3;
        }
    }
}

class B {
    boolean status = true;

    Float function opearationB(int: theNumber){
        if(status == true){
            return a.operationA(aNumber);
        }
    }
}

为了正确测试 A.operationA()，我必须编写至少三个单元测试（aNumber = 0、aNumber > 0 和 aNumber

现在假设我要测试 B.functionB，使用黑盒策略，我是否应该重新编写类似的三个单元测试（theNumber= 0、theNumber> 0 和theNumber

【问题讨论】：

为什么有黑盒测试要求？
class A 的测试就足够了。 class A 是 B 类的依赖项。在测试 B 时，可以模拟/伪造 A 类，以便仅测试 B 的附加功能。无需重新测试已经涵盖的功能。
@dm03514 在这种情况下使用黑盒策略将允许单元测试在操作A 更改时失败并返回更改操作B 结果的结果。仅通过检查 operationA 是否已在 operationB 中调用（白盒策略）是无法实现的。

标签： unit-testing oop black-box-testing

【解决方案1】：

如果可以放松黑盒约束，您可以删除所有重复项。我真的很喜欢 Jay Fields 对单独单元测试与社交单元测试的定义，explained here。

单独测试A 类应该是微不足道的。它没有副作用，也没有合作者。理想情况下，B 类也可以单独（单独）测试，其中它的合作者 A 类被剔除。这不仅可以让您单独练习B 课程，还有助于控制级联故障。如果 B 类在 A 类更改时与现实生活中的 A 类一起测试，则可能导致 B 类失败。

在某些时候应该检查协作（社交），可能有几种方法：

通过其公共接口调用 b 并触发 A 类中的默认情况的单个社交测试
执行特定用户故事或外部流程路径的更高级别测试，触发 B 类

很抱歉没有回答您的直接问题。

【讨论】：