TDD 是基于单元测试的吗？
Is TDD based on unit test?
我搜索了很多，但找不到这个问题的正确答案。
一些文章定义了 TDD，您可以在其中进行任何类型的测试。
有些文章只是说TDD只是做功能测试，到了验收测试就BDD而不是TDD了。
所以...
TDD 真的只是单元测试吗？
对于什么是单元测试，还没有普遍接受的定义，因此该问题没有普遍接受的答案。
现代 TDD 是 Kent Beck 的发明（或 rediscovery）。如果您读过他的书 Test Driven Development: By Example，您会发现他使用了没有依赖性的小型确定性测试。这是一种常见的 TDD 方式，似乎符合大多数人对 单元测试.
的定义
另一方面，仅仅因为 Kent Beck 最初使用单元测试来演示 TDD 技术，并不排除其他类型的测试。另一个使用范围稍广的测试的重要资源是 Nat Pryce 和 Steve Freeman 的 Growing Object-Oriented Software, Guided by Tests。虽然他们不使用 Gherkin，但您可以将这种方法视为与 BDD 相得益彰 - 至少，我将其称为一种 由外而内的 TDD.
我曾经有机会与 Dan North（BDD 的发明者）讨论这些技术的总体目的，我认为我们一致认为总体动机是 快速反馈。通过单元测试，您可以 运行 一个 mere seconds 中的测试套件。这几乎可以立即为您提供有关 API 设计和实施的反馈。
如果其他类型的测试也能给你类似的feedback，它符合TDD的整体激励框架。您所说的测试到底是什么并不重要。
但要回答明确的问题：
Is TDD really just unit test?
不，测试驱动开发 (TDD) 是一个过程，在这个过程中您编写（单元）测试并让您从这些测试中收到的反馈指导您弄清楚什么接下来要做的。常见的 TDD 工作流是 red-green-refactor cycle.
Is TDD really just unit test?
没有
The problem with driving development with small-scale tests (I call them "unit tests", but they don't match the accepted definition of unit tests very well).... -- Kent Beck, 2003
迈克尔·费瑟斯，writing in 2005
...there is a failure case for teams that attempt to get test infected; you can end up writing very slow tests that take so long to run that they essentially start to feel like baggage even though they help you catch errors.
重要的想法是测试要快速且可靠（这样它们就不会阻碍“重构”任务）。但这并不一定意味着测试对象需要小.
也就是说，我们所说的测试是 程序员 测试：它们用于支持产品代码的制作。支持其他利益相关者的测试是另一回事，受到不同的约束。
我搜索了很多，但找不到这个问题的正确答案。 一些文章定义了 TDD，您可以在其中进行任何类型的测试。 有些文章只是说TDD只是做功能测试，到了验收测试就BDD而不是TDD了。 所以...
TDD 真的只是单元测试吗？
对于什么是单元测试，还没有普遍接受的定义，因此该问题没有普遍接受的答案。
现代 TDD 是 Kent Beck 的发明（或 rediscovery）。如果您读过他的书 Test Driven Development: By Example，您会发现他使用了没有依赖性的小型确定性测试。这是一种常见的 TDD 方式，似乎符合大多数人对 单元测试.
的定义另一方面，仅仅因为 Kent Beck 最初使用单元测试来演示 TDD 技术，并不排除其他类型的测试。另一个使用范围稍广的测试的重要资源是 Nat Pryce 和 Steve Freeman 的 Growing Object-Oriented Software, Guided by Tests。虽然他们不使用 Gherkin，但您可以将这种方法视为与 BDD 相得益彰 - 至少，我将其称为一种 由外而内的 TDD.
我曾经有机会与 Dan North（BDD 的发明者）讨论这些技术的总体目的，我认为我们一致认为总体动机是 快速反馈。通过单元测试，您可以 运行 一个 mere seconds 中的测试套件。这几乎可以立即为您提供有关 API 设计和实施的反馈。
如果其他类型的测试也能给你类似的feedback，它符合TDD的整体激励框架。您所说的测试到底是什么并不重要。
但要回答明确的问题：
Is TDD really just unit test?
不，测试驱动开发 (TDD) 是一个过程，在这个过程中您编写（单元）测试并让您从这些测试中收到的反馈指导您弄清楚什么接下来要做的。常见的 TDD 工作流是 red-green-refactor cycle.
Is TDD really just unit test?
没有
The problem with driving development with small-scale tests (I call them "unit tests", but they don't match the accepted definition of unit tests very well).... -- Kent Beck, 2003
迈克尔·费瑟斯，writing in 2005
...there is a failure case for teams that attempt to get test infected; you can end up writing very slow tests that take so long to run that they essentially start to feel like baggage even though they help you catch errors.
重要的想法是测试要快速且可靠（这样它们就不会阻碍“重构”任务）。但这并不一定意味着测试对象需要小.
也就是说，我们所说的测试是 程序员 测试：它们用于支持产品代码的制作。支持其他利益相关者的测试是另一回事，受到不同的约束。