TDD是基于单元测试的吗？

Question

我搜索了很多，但找不到这个问题的正确答案。 有些文章定义了 TDD，您可以在其中进行任何类型的测试。 刚才有文章说TDD就是功能测试，验收测试是BDD而不是TDD。 所以...

TDD 真的只是单元测试吗？

Answer 1

对于什么是单元测试，没有普遍接受的定义，因此该问题不可能有普遍接受的答案。

现代 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 相得益彰 - 至少，我将其称为一种 outside-in TDD。

我曾经有机会与 Dan North（BDD 的发明者）讨论这类技术的总体目的，我认为我们一致认为总体动机是快速获得反馈。通过单元测试，您可以在mere seconds 中运行测试套件。这几乎可以立即为您的 API 设计和实施提供反馈。

如果其他类型的测试可以给你类似的feedback，它符合TDD的整体激励框架。你所说的测试并不那么重要。

但要回答明确的问题：

TDD 真的只是单元测试吗？

不，测试驱动开发 (TDD) 是一个过程，您可以在其中编写（单元）测试，并让您从这些测试中收到的反馈指导您确定下一步该做什么。一个常见的 TDD 工作流是red-green-refactor cycle。

Answer 2

TDD 真的只是单元测试吗？

没有

使用小规模测试推动开发的问题（我称它们为“单元测试”，但它们与单元测试的公认定义不太匹配）....——Kent Beck，2003 年

迈克尔·费瑟斯，writing in 2005

...尝试感染测试的团队存在失败案例；您最终可能会编写非常慢的测试，这些测试需要很长时间才能运行，即使它们可以帮助您发现错误，它们实际上也开始感觉像是包袱。

重要的想法是测试要快速可靠（这样它们就不会妨碍“重构”任务）。但这并不一定意味着测试对象需要小。

也就是说，我们所说的测试是程序员测试：它们的存在是为了支持产品代码的制作。支持其他利益相关者的测试是另一回事，受到不同的约束。