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

我同意你的观点,这个例子是关于类显示缺少单元测试的。

然而,该示例的作者可能想指出,单元之间的耦合可以更强 比预期的或合同中描述的要多。此外,这个示例已经清楚地表明,在集成级别上 在单元测试级别上,事情可能会不同于预期(可能不是为了 SetRPMtoZero方法在CalculateAverage方法之前调用)。 通常在单元测试级别上看不到这一点,除非您有世界上最好的规范。

那么,在集成单元时可能会遇到什么其他问题(同时,这也是单元测试无法告诉您的):

• 即使在集成测试的第一阶段,集成本身(例如,如果我们谈论像c++这样的语言,将单元链接在一起), 如果一个单元中的接口发生更改,但另一个单元中的接口未相应调整,则可能会失败。
• 如果单元使用公共资源(如文件、内存),则资源的保留/释放可能会导致阻塞状态或数据损坏
• 如果您百分之百地覆盖一个单元测试的源代码,这并不意味着所有代码都是真正必要的。关于集成 级别您可能会意识到,当将单元组合在一起时,有很多代码甚至无法达到。这可以帮助你发现, 代码的哪些部分可能是“死代码”。
• 性能限制或资源限制(如内存有限)
• 对合同的误解或执行中的错误

有趣的问题。一方面,这很愚蠢。显然,一定有某种逻辑无法通过单元测试发现,否则单元测试就是Delphi的预言。

我认为这里重要的哲学思考是涌现复杂性的概念。许多思想家过去都指出了这一点。摩尔定律可能是最好的例子[晶体管的复杂度大约每2.5年翻一番]。但这是一个一般原则。

因此,要抽象出软件测试的紧急复杂性规律:5个软件单元是单独更复杂、相等还是不复杂,还是一起更复杂?当你这样说的时候,很明显,5个单元一起工作一定比单独的单元更复杂。这被称为“大于各部分之和”,是系统的一般规则。