22、测试驱动开发：开启软件之美的新境界

测试驱动开发：开启软件之美的新境界

1. 构建易读的规范

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

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

2. 永久需求工件

示例是详细阐述需求的永久工件，而故事是用于细分、排序和规划系统增量开发的临时工件。我们的挑战是，从可能不连贯的小故事中逐步构建出系统需求的连贯大图，每个故事可能会添加新示例或修改现有示例。

例如，在迭代过程中，会将功能描述（需求）与相应示例无缝集成到永久工件中。随着迭代推进，初始成功场景会通过一系列“如果……会怎样”的问题得到增强，这些问题会关联到更多业务规则描述及其示例。最终的需求工件需要以连贯的方式整合需求和示例，这是软件需求的新美观标准。

3. 可测试的设计

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