BDD 与DSL 入门

正文：

　　Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。
在了解Behavior Driven Development之前，先介绍Test-Driven Development(TDD)即测试驱动开发，它是一种测试先于编写代码的思想用于指导软件开发。测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。

TDD方法的一些特点：

有利于更加专注软件设计；
清晰地了解软件的需求；
很好的诠释了代码即文档。

之前一直对于测试都是一个笼统的认知，觉得测试仅仅是一种验证，类似于部分企业中一些比较省事的测试方法，通常在代码写好之后再实施测试工作，用于验证developer的代码是否符合需求。稍微了解TDD、BDD之后才发现，测试不仅仅是一种对于代码的验证，找出几个bug或者一些诸如压力测试、负载测试，更是一种约束，一种规范，是与项目需求息息相关，还需要沟通协调客户、开发人员以及QA，从而帮助更加高效的完成软件设计开发工作。

从图中可以发现，最下面的是单元测试（白盒测试），主要用于测试开发人员编写的代码是否正确，这部分工作都是开发人员自己来做的。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。再往上，就是BDD（灰盒测试、黑盒测试），主要用于测试代码是否符合客户的需求，这里的BDD更加侧重于代码的功能逻辑。

　　从左边的范畴也可以看出，测试的范围也是逐层扩大，从单元测试的类到BDD里面的服务、控制器等，再到最上层的模拟实际操作场景的Selenium（Selenium也是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。）对于包括UI界面的测试。之前自己有做过这样的编码测试工作，通过写代码，可以打开IE、FF等浏览器，模拟用户点击、填写数据等操作，从而完成一整套的流程测试。整个测试从小到大，从函数、方法、类到功能模块乃至系统有着一系列严谨的体系。

再说BDD

　　BDD是一种敏捷软件开发的技术。它对TDD的理念进行了扩展，在TDD中侧重点偏向开发，通过测试用例来规范约束开发者编写出质量更高、bug更少的代码。而BDD更加侧重设计，其要求在设计测试用例的时候对系统进行定义，倡导使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。

　　BDD的通用语言是一种近乎自然语言的描述软件的形式。传统的开发模式中，客户很难从技术层面理解问题，开发人员很难从业务需求考虑问题，基于这种通用语言形式可以尽可能的避免客户和开发者在沟通上的障碍，实现客户和开发者同时定义系统的需求。避免了因为理解需求不充分而带来的不必必要的工作量。

　　BDD描述的行为就像一个个的故事(Story)，系统业务专家、开发者、测试人员一起合作，分析软件的需求，然后将这些需求写成一个个的故事。开发者负责填充这些故事的内容，测试者负责检验这些故事的结果。通常，会使用一个故事的模板来对故事进行描述。

总结：

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)
  - 只有在一个明确的小领域下,才有意义.
分类
- 外部DSL.
  - 通常使用自定义语法(或XML等), 宿主应用会采用文本解析技术, 对外部DSL 脚本进行解析.
    - 例如: 正则表达式, SQL, Awk.
- 内部DSL.
  - 通用语言的特定用法, 其脚本是具有特定风格的合法的程序.
  - 与外部DSL 的区别: 内部DSL 使用可执行的语言编写,然后在该语言中解析.
    - 例如: Lisp,Rails.
- 语言工作台.
  - 专用的IDE, 用以定义和构建DSL.
抽象: 将DSL看做一种处理抽象的方式.
- 建立抽象的方式是程序库或框架. 通过命令/查询式API调用来操作框架.
  - DSL是程序的前端, 提供了不同于命令/查询式API风格的操作方式.
  - 程序库成为DSL的”语义模型”.
  - 通常以DSL加程序库的方式出现.
API和DSL的核心区别为: DSL 具有语言性.
DSL的问题
- 语言噪音. 学习DSL 应该比学习底层模型的代价小.
- 构建成本. 可维护性是重要的考量.
- 语言集中营. 分离关注点来让DSL有清晰的受限范围; 自行构造应从外部获得的东西.
- DSL是”不断演化,尚未完结”的事物.
  - 遇到不符合抽象的事物,应该修改抽象,让其更容易的接纳新事物.