监视受过测试的班级是不好的做法吗？

我正在一个项目中进行类内部调用，但是结果是简单值的很多倍。示例（不是真实的代码）：

public boolean findError(Set<Thing1> set1, Set<Thing2> set2) {
  if (!checkFirstCondition(set1, set2)) {
    return false;
  }
  if (!checkSecondCondition(set1, set2)) {
    return false;
  }
  return true;
}

为这种类型的代码编写单元测试真的很困难，因为我只想测试条件系统而不是实际条件的实现。（我在单独的测试中这样做。）实际上，如果我传递实现条件的函数会更好，而在测试中我只提供一些模拟即可。这种方法的问题在于嘈杂：我们大量使用泛型。

一个可行的解决方案；但是，这是使被测对象成为间谍并模拟对内部函数的调用。

systemUnderTest = Mockito.spy(systemUnderTest);
doReturn(true).when(systemUnderTest).checkFirstCondition(....);

这里的关注点是有效更改了SUT的实现，并且使测试与实现保持同步可能会出现问题。这是真的？是否有最佳实践来避免这种内部方法调用的麻烦？

请注意，我们正在谈论的是算法的各个部分，因此将其分解为多个类可能不是一个理想的决定。

单元测试应将其测试的类视为黑盒。唯一重要的是它的公共方法以预期的方式运行。类如何通过内部状态和私有方法实现此目标无关紧要。

当您认为无法以这种方式创建有意义的测试时，则表明您的类过于强大且执行了太多操作。您应该考虑将其某些功能移到可以单独测试的单独的类上。

如果findError()和checkFirstCondition()等都是类的公共方法，则findError()实际上是同一API已有功能的外观。这样做没有错，但是这意味着您必须为此编写与现有测试非常相似的测试。此重复仅反映您公共接口中的重复。没有理由将此方法与其他方法区别对待。

单元测试应测试合同；对他们来说，这是唯一重要的事情。测试不属于合同的任何内容不仅浪费时间，而且是潜在的错误来源。每当您看到开发人员在更改实施细节时更改测试时，都会响起警钟。开发人员可能（无论有意还是无意）隐藏了自己的错误。 故意测试实现细节会加剧这种不良习惯，从而更容易掩盖错误。

内部调用是一个实现细节，仅应在衡量性能时感兴趣。通常这不是单元测试的工作。

首先，我想知道您编写的示例函数有哪些难以测试的地方？据我所知，您可以简单地传递各种输入并检查以确保返回正确的布尔值。我想念什么？

对于间谍而言，使用间谍和模拟的所谓“白盒”测试的编写工作量增加了几个数量级，不仅因为要编写的测试代码太多，而且任何时候实现更改后，还必须更改测试（即使接口保持不变）。而且这种测试还不如黑盒测试可靠，因为您需要确保所有额外的测试代码都是正确的，并且您可以放心，如果黑盒单元测试与接口不匹配，它将失败。 ，您不能相信代码会过度使用模拟，因为有时测试甚至不会测试很多真实的代码-仅模拟。如果模拟不正确，则很有可能是您的测试将成功，但是您的代码仍然被破坏。

任何有白盒测试经验的人都可以告诉您，编写和维护它们很麻烦。加上它们可靠性较低的事实，白盒测试在大多数情况下简直逊色。