SDD开发实例（2）

敏捷开发，基本上属于现在软件开发的主潮流。但是很多人还没有真正的理解它。敏捷开发并不是指特定某种开发模式，而是概指所有符合以下特性的任意开发模式：通过更加频繁有效的交流，更早的发现问题，解决问题。

基本上主流的敏捷方法，都是依赖于测试的质量，所以测试驱动开发（Test Driven Development）可以称为敏捷开发的基柱。TDD的思想就是通过测试活动来驱动开发活动从而达到将客户需求能够精确的反应到开发过程中，从而降低开发的成本。在这过程中，最典型的特点就是先完成测试程序，在实现能够通过测试程序验收的代码，经过反复迭代，从而使得产品顺利发布。

在TDD的进化过程中，出现了一个更加有趣的BDD分支，即行为驱动开发（Behavior. Driven Development）。在不断的迭代过程和OO思想影响下，我们会发现有很多产品的设计思路从总体来看就是一些特定对象的行为集合。我们的产品，就是不断的完善这些对象的行为。因此，TDD的真正价值就在于能够更加清晰有效的对对象的行为进行分解实现。对于拥有BA的开发团队，一般将用户的需求描述为产品的设计理念，例如UML的介入，大量的流程图和关系图的出现，将简单的需求复杂化，模块化。那么为什么不直接从真正用户如何使用产品入手呢？这样我们直接就从客户的角度考虑，如何设计产品，从而使其的行为能够符合用户的习惯（UE）和流程。BDD就是依据这一理念出现了。

BDD通过定义用户和开发团队所共同接受的“通用语言”来实现对接。从而避免双方表达不一致的出现，导致产品开发出现产品功能偏差。

而SDD（Story Driven Development）就是对BDD的一种具体的实现。使用Story来定义用户和系统行为，从而达到测试驱动开发的目的。

一般常用的story格式如下：

Story：subject                           

As a（role）

In order to（behavior）

So that（benefit）

然后通过一系列的场景来验证该story的实现。

如果我们把AC看作test case outline，这些scenario就等同于一个个我们要使用的test case。

一个scenario一般是如下格式：

Scenario 1：subject

Given【上下文】

          And【更多的上下文或步骤】

When【要完成的事件】

Then【期望的结果】

          And【更多的期望结果】

场景很容易去理解，Given和And给出了一些的上下文，就等同于测试用例中的precondition和steps。When给出的就是最后要验证的系统的behavior或者要验证的操作。Then和And给出的是这个behavior或者操作的正确期望结果。

Story，As a，In order to，So that，Scenario，Given，And，When，Then这些就是我们在SDD这种模式中定义的用户和开发团队所共同接受的“通用语言”的一些关键词。SDD框架能够理解和解释这些关键词从而使得SDD得到实现。

而Cucumber就是一个实现的SDD框架。它通过feature文件来保存story和相关的scenario。使用任意支持的语言来完成scenario中的steps与自动化测试脚本的mapping。然后就可以在执行feature文件时，直接执行相关的自动化测试脚本。