0

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

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。

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

4

2 回答 2

0

I agree with you that the example rather is about a missing unit test for the class Display.

However, maybe the author of that example wanted to point out that the coupling between units can be stronger than expected or than described in a contract. Furthermore this example makes already clear that on integration level things can be different than expected on unit test level (maybe it was not intended that the SetRPMtoZero method is called just before the CalculateAverage method). Usually you don't see that on unit test level, unless you have the best specification in the world.

So, what else you may encounter when integrating your units (at the same time this is also what unit-tests can't tell you):

  • Even on the first stage of integration test, the integration itself (f.e. linking the units together, if we talk about a language like c++), can fail, if the interface changed in one unit, but not adapted accordingly in the other(s).
  • If the units use common resources (like a file, memory), then reservation/release of a resource may cause blocked states or data corruption
  • If you cover the source code of a unit by unit test with 100% than this does not mean that all of the code is really necessary. On integration level you may realize that there is lot of code, which can't even be reached, when putting the units together. This can help you to find out, which parts of your code are probably "dead code".
  • Performance restrictions or resource limits (like limited memory)
  • Misinterpretation of the contract or errors in its implementation
于 2018-05-02T22:55:28.353 回答
-1

有趣的问题。一方面是愚蠢的。显然，一定有某种逻辑是单元测试无法发现的，否则单元测试就是德尔福的预言机。

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

因此，将涌现复杂性定律抽象为软件测试：5 个软件单元是分别更复杂、相等还是更复杂，还是加在一起更复杂？当你这样说时，很明显 5 个单元一起工作必须比单独的单个单元更复杂。这被称为“超过各部分的总和”，是系统的一般规则。

于 2018-04-30T08:35:12.750 回答