【译】什么是测试驱动开发

原文链接：https://www.agilealliance.org/glossary/tdd/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'tdd))~searchTerm~'~sort~false~sortDirection~'asc~page~1)

定义

测试驱动开发，英文名 Test-driven development，讲的是一种编程风格。

主要有三种流程紧密的过程交织在一起：

• 编码

• 测试（以编写单元测试的形式）

• 设计（以重构的形式）

它可以用以下一套规则来简洁的描述：

• 写一个单元测试，来描述程序的一个方面

• 运行测试，如果程序缺少了功能会导致失败

• 编写“足够的”的代码，尽可能简单，以使得测试通过

• “重构代码”，直到它符合简单性标准

• 重复，随着时间的推移“积累”单元测试

期望的收益

如果这样做的可能会收获到的好处：

• 团队的代码 bug 率的显著降低，但代码是初始开发工作的适度增加

• 相同的团队报告说这些间接的费用被项目最后阶段的工作减少所抵消

• 尽管迄今为止的实证研究未能证实这一点，但资深从业者报告说，TDD 可以提高代码中的设计质量，并且更普遍地提高“内部”或技术质量，例如提高内聚和耦合的指标

常见的陷阱

典型的个人错误包括：

• 忘记经常运行测试

• 一次写太多的测试

• 编写规模过大或粒度过粗的测试

• 编写过于琐碎的测试，例如省略断言

• 为琐碎的代码编写测试，例如访问器

典型的团队误区包括：

• 部分采用——团队中只有少数开发人员使用 TDD

• 测试套件维护不善--最常见的是导致测试套件的运行时间过长

• 废弃的测试套件（即很少或从未运行过）--有时是由于维护不善，有时是由于团队人员流动造成的

起源

虽然在编程之前进行测试细化的想法并不是敏捷社区的原创，但 TDD 构成了一个突破，因为它将这个想法与“开发人员测试”的想法相结合，为开发人员测试提供了新的尊重。

• 1976 年：Glenford Myers 出版了“软件可靠性”，其中指出“开发人员不应该测试自己的代码”的“公理”（开发人员测试的黑暗时代）

• 1990：以“黑盒”技术为主的测试学科，特别是以“捕获和回放”测试工具的形式

• 1991 年：在 Taligent 独立创建了一个测试框架，与 SUnit 有惊人的相似之处（来源：SUnit）。

• 1994 年：Kent Beck 为 Smalltalk 编写了 SUnit 测试框架（来源）

• 1998：关于极限编程的文章提到“我们通常先写测试”（来源）

• 1998 年到 2002 年：“Test First”被详细阐述为“Test Driven”，特别是在 C2.com Wiki 上

• 2000：模拟对象是那个时期开发的新技术之一（来源）

• 2003 年：Kent Beck 出版了“测试驱动开发：示例”

到 2006 年，TDD 已经是一门相对成熟的学科，它已经开始鼓励由它衍生的进一步创新，如 ATDD 或 BDD）。

使用的标志

• “代码覆盖率”是证明使用 TDD 的常用方法；虽然高覆盖率并不能保证正确使用 TDD，但低于 80% 的覆盖率可能表明团队对 TDD 的掌握不足

• 版本控制日志应显示每次签入产品代码时都会签入测试代码，数量大致相当

技术水平

初学者

• 能够在编写相应的代码之前编写一个单元测试

• 能够改写足以使失败的测试通过的代码

中级

• 实践“测试驱动的错误修复”：当发现缺陷时，在纠正之前编写一个暴露缺陷的测试

• 能够将一个复合程序的特征分解成若干单元测试的序列来编写

• 知道并能说出一些指导编写测试的策略（例如，"当测试一个递归算法时，首先为递归终止的情况编写一个测试"）。

• 能够从现有的单元测试中找出可重用的元素，产生特定情况的测试工具

高级

• 能够为宏观特征制定计划中的单元测试 "路线图"（并在必要时进行修改）

• 能够 "测试驱动 "各种设计范式：面向对象、功能化、事件驱动

• 能够 "测试驱动 "各种技术领域：计算、用户界面、持久性数据访问......。

延伸阅读

Test Driven Development: By Example, by Kent Beck