测试驱动开发：驱动软件之美的新标准
1. 迈向易读的规范
创建特定领域测试语言（DSTL）可使脚本更易读，前提是规范词汇具有声明性，并以业务领域目标和现实世界对象来表达。例如，DSTL的某一行可能等同于测试脚本的多行内容。不过，读者仍需从这些高级语句中拼凑出业务规则。
为DSTL添加简单的结构化语句，能让我们更接近完美的规范。如图所示，声明式、行为驱动的Given/When/Then风格有助于更清晰地表达业务规则。这种规范可以有多种呈现形式，如表格、文本、图形（如各种UML符号）、工作流故事板、UI线框等，关键是找到最能表达业务领域概念的形式。
1.1 永久需求工件
示例是阐述需求的永久工件，而故事是用于细分、确定优先级和规划系统增量开发的临时工件。我们的挑战是，从可能相互脱节的小故事中逐步构建出系统需求的连贯全貌，每个故事可能会添加新示例或修改现有示例。
例如，在迭代过程中，会选择在首次迭代中实现特定功能的成功故事。图中故事以灰色阴影表示其临时性，图表右侧是包含功能描述（需求）和相应示例的永久工件的首次增量。后续迭代中，永久规范会逐步完善，初始成功场景会通过一系列“如果……会怎样”的问题得到增强，这些问题会关联到更多业务规则描述及其示例。最终的需求工件需要以连贯的方式整合需求和示例，这为软件需求树立了新的美观标准。
2. 可测试的设计
与其他规范形式不同，测试驱动开发（TDD）直接影响软件设计。若正确实践，TDD能确保设计具有高度可测试性。一个可测试的系统应具备以下特点：
- 设置系统/组件及所有依赖系统/组件的初始状态。
- 控制环境因素，如日期和时间。
-
