BDD和ATDD、实例化需求有何区别？

BDD和ATDD、实例化需求有何区别？

在软件开发领域，BDD（行为驱动开发）、ATDD（验收测试驱动开发）和实例化需求是三个经常被提及的概念。它们之间有何区别？本文将从TDD（测试驱动开发）开始，逐步解析这些开发方法的核心理念和实践方式。

TDD

TDD，即测试驱动开发，是由Kent Beck在1999年提出的，强调测试先行，避免过度设计。TDD的核心流程可以概括为“红-绿-重构”三步骤：

1. 编写一个失败的测试（测试工具显示为红色）
2. 编写生产代码，使测试通过（测试工具显示为绿色）
3. 在保证所有测试通过的情况下，重构代码以提升可读性和可维护性

TDD主要面向开发人员，通过强制设计可测试的程序，不断重构代码来提升代码质量，完善的测试体系充当保护网，并提供快速反馈。

ATDD

ATDD现在被普遍认为是Acceptance Test-Driven Development，即验收测试驱动开发。

2002年，Kent Beck在《Test-Driven Development by Example》一书中首次提到ATDD，当时指的是应用程序级别的测试驱动开发（Application Test-Driven Development）。虽然与Acceptance的字面含义不同，但它们都强调用户参与编写测试用例，采用由外至内的开发方式。

Kent Beck当时对ATDD持保留态度，主要担忧包括测试装置的技术挑战、测试编写职责转移带来的额外投入，以及无法像TDD那样提供快速反馈。

同年，Ward Cunningham开发了集成测试框架FIT（Framework for Integrated Test），允许客户使用Excel提供验收标准实例，并实现自动化运行，解决了Kent Beck担忧的技术问题。随后，Robert C. Martin在Fit的基础上开发了流行的FitNesse。

2004年，Tracy Reppert在Better Software杂志上发表了一篇名为《How Story Test-Driven Development is changing the way QA, customers, and developers work》的文章，首次提到了STDD（故事测试驱动开发），作为XP极限编程的一种实践。STDD的核心流程包括：

1. 定义故事（由主题专家/业务分析师完成）
2. 定义故事测试（由主题专家/业务分析师、测试人员和开发人员协作完成）
3. 将故事测试签入版本控制系统SCM
4. 编写测试代码，实现功能，使故事测试通过（由开发人员完成）

STDD的成功实践证明了测试编写职责转移的问题在敏捷XP方法下并非障碍。

随着Fit/FitNesse等工具的兴起，ATDD获得了普及并成为一种更受认可的开发方法。现在，ATDD被普遍认为是一种基于业务客户、开发人员和测试人员之间沟通的开发方法。

实例化需求

不论是TDD还是ATDD，它们都是以“测试”来命名的，但ATDD并不仅仅关注在验收测试方面，其核心理念是通过业务客户、开发人员和测试人员之间的协作，将业务需求以实例化的方式转化为可自动化执行的验收测试，以此驱动开发出正确的软件。

2011年，Gojko Adzic在《Specification by Example》一书中提出了实例化需求的概念，他认为“测试”一词可能无法被业务人员理解，业务人员常常以“测试并非需求工作”为由拒绝参与相关会议。因此，他使用了术语实例化需求，有时候也被称为SBE。Gojko Adzic还认为实例化需求实践的核心内容和BDD是一样的，他不想使用术语BDD，仅仅是因为担心这组实践和BDD之间产生任何混淆或者歧义。

读到这里，相信你应该得到了答案。BDD、ATDD和实例化需求，本质上并无区别。同样的术语还有：

• STDD，Story Test-Driven Development，故事测试驱动开发
• EGD，Example-Guided Development，实例指导开发
• EDD，Example-Driven Development，实例驱动开发
• Agile Acceptance Testing，敏捷验收测试
• Story Testing，用户故事测试

本文引用：

• 《Test-Driven Development by Example》
• 《ATDD by Example》
• 《Specification by Example》
• 《Lean-Agile Acceptance Test-Driven Development》
• 《BDD In Action, 2nd edition》
• 《How Story Test-Driven Development is changing the way QA, customers, and developers work》