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

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

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

但是TDD发生了；肯特贝克对他的定义并不特别自律，一堆新想法开始冒出来。

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

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

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

因此，出现了一种不同类型的约束，表明测试对象应该很小——“单元测试”是指测试对象的行为仅取决于可能发生变化的少量决策。

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

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

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

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

如果我们更改设计以在不稳定部分之间共享工作，这仍然是单元测试吗？我相当肯定贝克会同意，弗里曼和普莱斯也会同意。我不太确定@JBrains；请参阅综合测试是骗局。有些人做了自己的实验，并找到了适合他们的职位；其他人对他们喜欢的专家所描述的“最佳实践”有自己的解释。

简而言之：这是一团糟。

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

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