如果一个方法调用另一个方法，它是单元测试还是集成测试？

Question

我是 tdd 概念的初学者，所以我的问题是，如果我有一个方法调用另一个方法，听起来很简单，它是单元测试还是集成测试？如果是集成测试，那只是因为我的方法调用了另一个方法并且方法之间存在“集成”？

Answer 1

如果我有一个方法调用另一个方法，听起来很简单，它是单元测试还是集成测试？

可悲的是，这将取决于您使用的“单元测试”和“集成测试”的定义。二十年前，当这些定义由软件测试领域的专家提出时，这个问题会更容易回答。

但是 TDD 发生了；肯特·贝克 (Kent Beck) 对他的定义并不特别自律，于是一堆新想法开始涌现。

即使在 TDD 的上下文中，对于“单元测试”的含义也存在微妙的分歧。例如，一个重要的想法是测试不应对其运行顺序敏感；每个单独的测试都包含正确测量系统所需的所有设置和拆卸。另一个是在同一进程中同时运行的两个测试不应相互干扰；所以没有共享的可变状态..

这里的共同主题是测试受到约束；“单元测试”将描述具有一组特定属性的测试。

一个不同的想法来自观察大型测试，如果没有非常仔细的设计，在项目的整个生命周期中都是脆弱的。如果测试对象的可观察行为又取决于许多可能会改变的不同决定，那么脆弱测试是一个常见的结果。

因此，出现了一种不同类型的约束，这表明测试对象应该很小——“单元测试”是其中测试对象的行为仅取决于可能会改变的适度数量的决定的测试。

更令人困惑的是，贝克和其他人使用并取得了一些成功的仪式在不同时期被宣传为“测试优先开发”、“测试驱动开发”、“测试驱动设计”——这混淆了动机。是目的test，还是目的design？

据我所知，每个人都同意不委托任何工作的方法是单元测试的一个很好的主题。

此外，每个人都同意将其工作委托给稳定的合作者（例如标准库）的方法是单元测试的一个很好的主题。

但是，当我们将不使用合作者的设计替换为使用不稳定合作者的设计（将工作委托给其他方法，特别是如果它们在不同的“类”中时）时，分歧就开始了。

如果我们更改设计以在不稳定部件之间共享工作，它仍然是单元测试吗？我相当确定贝克会同意，就像弗里曼和普赖斯一样。我不太确定@JBrains；请参阅集成测试是一个骗局。有些人做了自己的实验，并找到了适合自己的位置；其他人对他们偏爱的专家描述的"最佳实践"有他们的解释。

简而言之：这是一团糟。

我能提供的最佳答案是，与其担心我们用于不同风格测试的标签，不如专注于有趣的属性集、确保测试具有这些属性所需的约束，以及将这些属性与其用途对齐.

例如，如果您要在开发会话期间多次运行测试，作为早期发现错误的一种机制，那么您可能希望这些测试快速且独立于您自己以外的环境中发生的事情。为了获得这些属性，您可能需要在测试中避免网络流量，甚至可能需要避免 I/O——在内存中做“所有事情”要快得多（并且让您面临某些需要管理的风险）其他方法）。