我是 tdd 概念的初学者，所以我的问题是，如果我有一个调用另一个方法的方法，听起来很简单，它是单元测试还是集成测试？如果它是一个集成测试，那只是因为我的方法调用了另一个方法并且方法之间存在“集成”？
最佳答案
if I have a method that calls another method, as simple as it may sound, it is a unit test or a integration test?
遗憾的是，这将取决于您使用的“单元测试”和“集成测试”的定义。二十年前，当这些定义是由软件测试领域的专家插入的时候，这个问题更容易回答。
但是 TDD 发生了；肯特·贝克 (Kent Beck) 对他的定义并没有特别严格的规定，于是一堆新想法开始涌现。
即使在 TDD 的上下文中，对于“单元测试”的含义也存在细微的分歧。例如，一个重要的想法是测试不应该对它们运行的顺序敏感；每个单独的测试都包含正确测量系统所需的所有设置和拆卸。另一个是在同一进程中同时运行的两个测试不应相互干扰；所以没有共享的可变状态..
这里的共同主题是测试是受约束的； “单元测试”将描述具有一组特定属性的测试。
一个不同的想法来自观察，如果没有非常仔细的设计，大型测试在项目的整个生命周期中都是脆弱的。如果测试对象的可观察行为反过来取决于许多可能改变的不同决策，那么脆弱测试是一个常见的结果。
因此出现了一种不同类型的约束，表明测试对象应该很小——“单元测试”是一种测试对象的行为仅取决于少量可能会发生变化的决定的测试。
更令人困惑的是，Beck 和其他人曾经成功使用的仪式在不同时期被称为“测试先行开发”、“测试驱动开发”、“测试驱动设计”——这混淆了动机。目的是测试，还是目的设计？
据我所知，每个人都同意不委托(delegate)其任何工作的方法是单元测试的好主题。
此外，每个人都同意将其工作委托(delegate)给稳定的协作者(例如标准库)的方法是单元测试的好主题。
但是，当我们将不使用协作者的设计替换为使用不稳定协作者的设计(将工作委托(delegate)给其他方法，尤其是当它们位于不同的“类”时)时，分歧就开始了。
如果我们改变设计让不稳定的部分分担工作，这还是单元测试吗？我相当确定 Beck 会同意，Freeman 和 Pryce 也会同意。我不太确定@JBrains；见Integrated Tests are a Scam .有些人已经完成了自己的实验，并找到了适合自己的工作；其他人有他们的解释 他们喜欢的专家描述的“最佳实践”。
简而言之:一团糟。
我能提供的最佳答案是，与其担心我们用于不同风格测试的标签，不如专注于有趣的属性集，约束您需要确保测试具有这些属性，并使这些属性与其用途保持一致。
例如，如果您打算在开发 session 期间多次运行测试，作为一种及早发现错误的机制，那么您可能希望这些测试速度快，并且独立于您自己外部环境中发生的情况。要获得这些属性，您可能需要避免测试中的网络流量，甚至可能需要避免 I/O——在内存中执行“所有操作”要快得多(并且让您面临某些需要管理的风险其他方式)。
关于unit-testing - 如果一个方法调用另一个方法，是单元测试还是集成测试？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55623912/