1. 客户不关心测试
客户只关心软件是否满足需求.-
Test 是验证行为(Verification).- 只有当软件存在后才能进行test.
-
BDD关注的是specification.BDD 是Design 行为.- 由预期的behaviour 驱动, 并逐步地构建功能块.
- 从Test 到 BDD:
-
由**test-centric** 视角转变为**specification-centric** 视角.
-
2. 客户不希望编写specification
- 客户不必编写自身问题的解决方案.
- 认知差异(cognitive diversity)
- �异类的(heterogeneous) 人员在一起工作.
- 我们可以帮助客户完成specification.
- 客户需要提供需要解决的问题的信息, 并提供具体事例来指导开发流程.
3. DSL: Domain Specific Language.
- 在组内促进了重要问题的沟通(BA,QA,DEV).
- 特征
- 语言特征(language nature)
- 具备连贯的表达能力.
- 受限的表达力(limited expressiveness)
- 只支持特定领域所需特征的最小集.
- 专注于特定领域(domain focus)
- 只有在一个明确的小领域下,才有意义.
- 语言特征(language nature)
- 分类
- 外部DSL.
- 通常使用自定义语法(或XML等), 宿主应用会采用文本解析技术, 对外部DSL 脚本进行解析.
- 例如: 正则表达式, SQL, Awk.
- 通常使用自定义语法(或XML等), 宿主应用会采用文本解析技术, 对外部DSL 脚本进行解析.
- 内部DSL.
- 通用语言的特定用法, 其脚本是具有特定风格的合法的程序.
- 与外部DSL 的区别: 内部DSL 使用可执行的语言编写,然后在该语言中解析.
- 例如: Lisp,Rails.
- 语言工作台.
- 专用的IDE, 用以定义和构建DSL.
- 外部DSL.
- 抽象:
将DSL看做一种处理抽象的方式.- 建立抽象的方式是程序库或框架. 通过命令/查询式API调用来操作框架.
- DSL是程序的前端, 提供了不同于命令/查询式API风格的操作方式.
- 程序库成为DSL的”语义模型”.
- 通常以
DSL加程序库的方式出现.
- 建立抽象的方式是程序库或框架. 通过命令/查询式API调用来操作框架.
- API和DSL的核心区别为:
DSL 具有语言性. - DSL的问题
- 语言噪音. 学习DSL 应该比学习底层模型的代价小.
- 构建成本. 可维护性是重要的考量.
- 语言集中营. 分离关注点来让DSL有清晰的受限范围; 自行构造应从外部获得的东西.
- DSL是”不断演化,尚未完结”的事物.
- 遇到不符合抽象的事物,应该修改抽象,让其更容易的接纳新事物.
