TDD 是基于单元测试的吗？

如何解决TDD 是基于单元测试的吗？

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

TDD 真的只是单元测试吗？

解决方法

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

现代 TDD 是 Kent Beck 的一项发明（或 rediscovery）。如果您阅读他的测试驱动开发：示例一书，您会发现他使用了没有依赖关系的小型确定性测试。这是执行 TDD 的常用方法，似乎符合大多数人对单元测试的定义。

另一方面，仅仅因为 Kent Beck 最初使用单元测试来演示 TDD 技术，它并不排除其他类型的测试。另一个使用更广泛的测试的重要资源是 Growing Object-Oriented Software,Guided by Tests，作者是 Nat Pryce 和 Steve Freeman。虽然他们不使用 Gherkin，但您可以认为这种方法与 BDD 相得益彰 - 至少，我将其称为一种由外到内的 TDD。

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

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

但要回答明确的问题：

TDD 真的只是单元测试吗？

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

,

TDD 真的只是单元测试吗？

没有

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

迈克尔羽毛，writing in 2005

...对于试图感染测试的团队来说，有一个失败案例；您最终可能会编写非常缓慢的测试，这些测试需要很长时间才能运行，以至于即使它们帮助您发现错误，它们基本上开始感觉像是包袱。

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

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