22、测试驱动开发与团队协作：铸就软件之美

测试驱动开发与团队协作：铸就软件之美

1. 迈向易读的规范

创建特定领域测试语言（DSTL）能让脚本更易读，前提是规范词汇具有声明性，能以业务领域目标和现实世界对象来表达。比如，DSTL 的某一行可能等同于测试脚本的多行内容，这是显著的改进，但读者仍需从这些高级语句中拼凑出业务规则。

为 DSTL 添加简单的结构化语句，能让规范更美观。类似 Given/When/Then 这种声明式、行为驱动的风格，能更清晰地表达业务规则。规范可以有多种格式，如表格、文本、图形（如各种 UML 符号）、工作流故事板、UI 线框等，关键是找到最能表达业务领域概念的格式。

1.1 永久需求工件

示例是阐述需求的永久工件，故事则是用于细分、排序和规划系统增量开发的临时工件。我们的挑战是，从可能相互脱节的小故事逐步构建系统时，最终形成一个连贯的系统需求全貌，因为每个故事可能会添加新示例或修改现有示例。

1.2 测试驱动开发的优势

测试驱动开发（TDD）与其他规范形式不同，它直接影响软件设计。如果正确实践，TDD 能确保设计具有高度可测试性，让人和工具能轻松完成以下操作：
- 设置系统/组件及所有依赖系统/组件的初始状态
- 控制环境因素，如日期和时间
- 完全隔离系统/组件与其依赖项
- 触发系统/组件上的操作
- 控制依赖系统/组件的响应
- 访问所有直接和间接（副作用）结果

1.3 可测试设计的对比

典型的三层架构虽分层良好，但测试往往很麻烦。控制和验证通常局限于 UI 和数据库层，而且由于代码中直接引用外部组件（操作系统功能或第