学习测试驱动开发

前言

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

测试驱动开发是一种在编程过程中控制恐惧的方法。

肯特-贝克

我们真是无比幸运！我们使用测试驱动开发已有多年。

自从为水星太空计划编写代码的开发人员实践打卡式测试驱动开发（Punch Card TDD）以来，已经过去了几十年。促进测试驱动开发的XUnit库可以追溯到本世纪初。事实上，肯特-贝克（Kent Beck）撰写了《测试驱动开发》（Test-Driven Development：By Example》（Addison-Wesley Professional，2002 年）并开发了 JUnit 框架的 Kent Beck 自称是"重新发现"（而非发明）了 TDD 实践。这句话证明了他的谦逊，但也是事实。TDD 与软件开发本身一样古老。

那为什么测试驱动开发还远未成为编写代码的标准方法呢？为什么当遇到进度压力，或需要削减 IT 预算，或（我个人最喜欢的）希望 "提高软件交付团队的速度 "时，测试驱动开发往往成为第一个被牺牲的实践？尽管 TDD 可以减少缺陷数量、简化设计、提高开发人员对自己代码的信心等经验和 实验证据俯拾即是，但人们还是提出了所有这些理由。

为什么 TDD 被勉强采用，又被轻易放弃？下面这些经常从那些不愿实践 TDD 的人那里听到的论点或许能解释其中的原因：

我不知道从哪里开始，也不知道如何开始。

也许最常见的原因是缺乏认识和接触。与其他技能一样，以测试驱动风格编写代码也需要学习。许多开发人员要么没有学习这项技能的外部诱因（时间、资源、指导、鼓励），要么没有学习这项技能的内在动力（克服自己的不情愿和恐惧）。

测试驱动开发在玩具程序或编码面试中有效，但在编写 "真实世界 "的代码时无效。

这是不真实的，但也是可以理解的。大多数测试驱动开发教程和书籍，包括这本书，都局限于从一个显而易见的领域中挑选相对简单的示例。从商业部署的应用程序（例如，金融机构、医疗保健管理系统或自动驾驶汽车）中摘取一段软件的实际代码来编写 TDD 文章或书籍是很困难的。首先，现实世界中的大部分代码都是专有代码，并不开源。另外，作者的职责是展示对最广泛受众具有吸引力的领域的代码。在高度专业化的领域中展示 TDD 是不合逻辑的，近乎蒙昧主义。这样做首先需要对该领域的神秘行话和术语进行冗长的解释。这就违背了作者的初衷：让 TDD 变得易懂、平易近人，甚至可爱。

尽管在 TDD 文献中使用真实世界的代码存在这些障碍，但开发人员经常使用测试驱动开发来编写生产软件。也许最好、最有说服力的例子就是JUnit 框架本身的单元测试套件。Linux 内核--可能是世界上使用最频繁的软件--正在通过单元测试得到改进。

事后编写测试就足够了；TDD 限制太多和/或过于迂腐。

这比偶尔听到的"单元测试被高估了"的咆哮更让人耳目一新！编写生产代码后再编写测试，比不编写测试要好得多。任何能提高开发人员对其代码的信心、减少意外的复杂性并提供真实文档的东西都是好东西。然而，在编写生产代码 之前编写单元测试，可以起到防止任意制造复杂性的作用。

TDD 引导我们简化设计，因为它提供了这两条实用规则作为护栏：

1. 只有在修复测试失败时才编写生产代码。

2. 只有当测试结果为绿色时，才大力重构代码。

测试驱动开发是否能保证我们编写的所有代码都能自动地、不可避免地成为最简单、最有效的代码？不能。任何实践、规则、书籍或宣言都无法做到这一点。要确保实现并保持代码的简洁性，这取决于将这些实践付诸实践的 ...