是否存在单元测试无法发现的逻辑/流错误类型？

Question

假设我已经定义了合同并且明确了要求（包括输入范围，边界值等），并且单元测试验证了所有这些条件，那么当我将这些单元放在一起时，是否仍然存在集成错误？我现在不考虑外部服务。我已经看到以下作为集成错误的示例，但我相信这只是单元级别的缺失测试：

class Engine
{
   int RPM;

   void SetRPMtoZero()
   {
      RPM=0;
   }
}

class Display
{
  CalculateAverage(Engine e)
  {
    if (e.IsRunning)
    {
      int X=smth/e.RPM;  //could be division by 0
    }
  }
}

class IntegratingClass
{
  Engine e
  Display d..

  ...

  e.SetRPMtoZero();
  d.CalculateAverage(e);

  //this sequence would lead to the division by zero

}

我认为这不会显示集成错误 - CalculateAverage根本没有检查RPM！= 0。

实际上是否存在一种单元测试无法发现的逻辑错误（或控制流）？

Answer 1

我同意你的看法，这个例子是关于类Display的缺失单元测试。

然而，也许该例子的作者想要指出单位之间的耦合可能比预期更强或比合同中描述的更强。此外，这个示例已经清楚地表明，在集成级别上，事物可能与单元测试级别上的预期不同（可能并不意味着在CalculateAverage方法之前调用SetRPMtoZero方法）。除非您拥有世界上最好的规格，否则通常您不会在单元测试级别上看到它。

那么，在集成单元时你可能遇到的其他问题（同时这也是单元测试无法告诉你的）：

• 即使在集成测试的第一阶段，如果接口在一个单元中更改，但在其他单元中没有相应地进行调整，那么集成本身（如果我们谈论像c ++这样的语言，将这些单元链接在一起）可能会失败。
• 如果单元使用公共资源（如文件，内存），则预留/释放资源可能会导致阻塞状态或数据损坏
• 如果您通过单位测试覆盖单位的源代码100％，这并不意味着所有代码都是必要的。在集成级别上，您可能会发现在将单元放在一起时，存在许多代码，甚至无法达到这些代码。这可以帮助您找出代码的哪些部分可能是“死代码”。
• 性能限制或资源限制（如有限的内存）
• 对合同的误解或其实施中的错误

Answer 2

有趣的问题。一方面这是愚蠢的。显然，必须存在某些通过单元测试无法发现的逻辑，否则单元测试将是Delphi的Oracle。

我认为这里重要的哲学思考是紧急复杂性的概念。许多思想家过去曾指出过这一点。摩尔定律可能是最好的例子[晶体管的复杂性大约每2。5年翻一番]。但这是一般的校长。

因此，将紧急复杂性的规律抽象为软件测试：5个软件单元是分别更多，相同还是更简单，更复杂？当你这样说时，很明显5个单元一起工作必须比单个单元分离得更复杂。这被称为“超过其部分的总和”，并且是系统的一般规则。