我应该添加白盒/黑盒冗余单元测试吗？

Question

我为我的项目编写了black-box单元测试。

在重构之后，我在我的代码中采用了一种strategy pattern 。

此代码被black-box单元测试覆盖，即使在refactoring之后也是如此。

但是我想知道：我是否应该添加white-box unit tests ，例如，检查每个策略是否在做应该做的事情？

还是这是redundant的，因为我已经有了检查final outcome的黑匣子？

Answer 1

一般测试和单元测试的主要目标之一是发现错误（参见 Myers、Badgett、Sandler：软件测试的艺术，或 Beizer：软件测试技术，以及许多其他）。 在您的项目中，您可能对此有更轻松的 position，但有许多软件项目，如果实现级别的错误逃到后期开发阶段甚至现场，将会产生严重后果。 有人说，你的目标应该是增加对代码的信心——这也是正确的，但信心只能是正确测试的结果。 如果您不进行测试以发现错误，那么在您完成测试后，我将根本对您的代码没有信心。

当发现错误是单元测试的主要目标时，尝试保持单元测试套件完全独立于实现细节可能会导致测试套件效率低下——也就是说，测试套件不适合发现所有可能存在的错误。成立。 不同的实现有不同的潜在错误。 如果您不使用单元测试来查找这些错误，那么任何其他测试级别（集成、子系统、系统）肯定不太适合系统地查找它们。

因此，您最初使用黑盒测试测试代码的声明已经让我怀疑测试套件首先是否完全有效。 因此，是的，我会为每个策略添加特定的测试。

但是，请记住，拥有一个有效的测试套件的目标是与另一个目标竞争，即拥有一个易于维护的测试套件。 但我认为发现错误是主要目标，而测试套件可维护性则是次要目标。 尽管如此，即使在进行白盒测试时，也要尽量降低维护工作量：只使用白盒测试来发现黑盒测试也找不到的错误。 并且，尝试在测试辅助函数之间隐藏实现细节的使用。