BDD敏捷开发入门与实战
1.BDD的来由
2003年，Dan North首先提出了BDD的概念，并在随后开发出了JBehave框架。在Dan North博客上介绍BDD的文章中，说到了BDD的想法是从何而来。简略了解一下BDD的历史和背景，有助于我们更好地理解。
1.1 TDD的困惑
Dan在使用TDD敏捷实践时，时常会有很多同样的困惑萦绕脑海，这也是很多程序员敏捷实践都想知道的：
- where to start
- what to test
- what not to test
- how much to test in one go
- what to call their tests
- how to understand why a test fails
1.2 同事的小框架
当Dan用上了一位同事编写的小框架agiledox时，灵感闪现！这个框架其实很简单，它基于JUnit测试框架，根据测试类名和方法名，将每个测试方法都打印为类似文档的输出。程序员们意识到这个小玩具可以帮它们做一些文档性的工作，于是就开始用商业领域语法命名他们的类和方法，让agiledox产生的输出能直接被商业客户、分析师、测试人员都看懂！
// CustomerLookup
// - finds customer by id
// - fails for duplicate customers
// - ...
public class CustomerLookupTest extends TestCase {
testFindsCustomerById() {
...
}
testFailsForDuplicateCustomers() {
...
}
...
}1.3 “Ubiquitous Language”
此时，恰逢Eric Evans发表了畅销书DDD(领域驱动设计)，其中描述了为系统建模时，使用一种基于商业领域模型的Ubiquitous Language，让业务词汇渗透到代码中。于是，Dan决定定义一种分析师、测试人员、开发者、业务人员、用户都能懂的”Ubiquitous Language”。
Feature: <description>
As a <role>
I want <feature>
So that <business value>
Scenario: <description>
Given <some initial context>,
When <an event occurs>,
Then <ensure some outcomes>.就这样，BDD的雏形就出现了！但这种类似BRD的文档是如何与我们程序员的代码结合到一起的呢？下一节我们就详细分析一下。
2.三个核心概念
Feature、Scenario、Steps是BDD的三个核心概念，体现了BDD的三个重要价值：
- Living Document
- Executable Specification by Example(SbE)
- Automated Tests
2.1 Feature
Feature就像是文档一样，描述了功能特性、角色、以及 最重要的商业价值。
2.2 Scenario
场景就是上面提到的规范Specification。Cucumber提供了Scenario、Scenario Outline两种形式。使用时要注意，在Cucumber官博上的一篇文章“Are you doing BDD? Or are you just using Cucumber?”给出了一个反模式。
Scenario Outline: Detect agent type based on contract number (single contract found)
Given I am on the "Find me" page
And I have entered a contract number
When I click the "Continue" button
And a contract number match is found
And the agent type is <DistributorType>
Then the contract number field will become uneditable
And the "Back" button will be displayed
And the following <text> and <input field type> will be displayed
Examples:
| DistributorType | input field type | text |
| Broker | Date of birth | Please enter your last name |
| TiedAgent | Last name | Please enter your date of birth |看出来了差别吧：Scenario Outline的核心依然应该是商业规则，而不能因为它对输入和输出的细化就将重点转移到UI界面。
Scenario: Customer has a broker policy so DOB is requested
Given I have a "Broker" policy
When I submit my policy number
Then I should be asked for my date of birth
Scenario: Customer has a tied agent policy so last name is requested
Given I have a "TiedAgent" policy
When I submit my policy number
Then I should be asked for my last name2.3 Steps
Steps就是实际编码了，我们要在Java中实现出Feature文件中各种场景对应的代码，让它变成“活文档”！
3.实战(上)：分布式集群构建
之所以选择这么一个例子来实战，是因为网上的大部分例子都很简单而且雷同。通过这个例子，也是想试验一下BDD对于“业务性”不强的而且还是分布式的系统（即基础设施或中间件）是否也能发挥作用。这次实战也是一次比较奇妙的经历，不少核心类、接口和关于系统设计的想法都在这个过程中自然涌现~
3.1 开发环境
IDE当然还是选择Intellij，并且开启Cucumber插件，因为本实例是基于Cucumber实现的（其实其他的框架如JBehave都非常类似）。然后新建Maven工程，引入以下依赖包：
<dependencies>
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-java</artifactId>
<version>1.2.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-junit</artifactId>
<version>1.2.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>3.2 编写feature文件
Feature相对比较好写，简单描述一下功能特性就行了。比如下面的集群自动创建功能：为了自动创建集群（功能），作为用户（角色），我想结点能自动互相发现形成集群以节省手工的工作量和时间（商业价值）。
Feature: Auto Cluster Creation
In order to create a cluster automatically
As a user
I want the nodes can discover each other on their own我们还需要一个启动类：
@RunWith(Cucumber.class)
@CucumberOptions(plugin={"pretty"}, features="src/test/resources", tags = {})
public class NodeDiscoveryStory {
}3.3 选择典型场景
为了简化，我只选了一个最简单的两结点集群建立的场景。首先结点1形成集群A，当结点2加入集群A后，集群中应有两个结点1和2。
Scenario: create a cluster
Given node-1 in cluster-A starts
When a new node-2 in cluster-A starts
Then cluster-A should have node: 1,2场景的选择和编写至关重要，本例的实践过程中就碰到了一些问题，下面做一点个人的经验总结：
- Given和When不要混淆：一个是环境上下文，一个是触发条件，例如”a cluster is running”和”a new node starts”。弄混的结果就是在场景1里的Given在2里又原封不动的变成When了。
- 场景是可验证的不能含糊：这一点上与Feature不一样。一开始我描述的场景就比较模糊不清，例如”Then the cluster can acknowledge the new node”，这种描述不够精确，不好验证对错。实际上仔细想想，BDD对应设计的高层次与行为结果的可验证是不矛盾的！
- 只选几个典型场景：在BDD中千万不要追求覆盖率和细粒度，否则就将丧失BDD对业务逻辑的表现力！在Feature文件里只描述最核心的东西，把覆盖率这种只有我们程序员和QA关心的东西隐藏起来，在更细粒度的Case中去完成。
此外，还有关于Given和When是否要细分出一些And条件，比如本例中的Given和When就都可以分别拆成createNode和createOrJoinCluster两步，但这样的话会导致成员变量增多而显得比较乱，因为Cucumber中的Given和And、When和And之间是不能携带过去对象的。所以从下一部分的编码实现中能看出，最终我还是没有拆的那么细。
3.4 Steps编码实现
编码实现是最痛苦也最有收获的！一开始时一无所有的茫然，不断重构最终终于找到比较合理的设计。注意：代码不要跟着场景的描述走，比如变量cluster起名为clusterA，那就限定死了！我们的Steps应该是通用的，这里的Given、When都是可能用于其他场景的。
首先在@Given中启动一个Cluster加入一个Node，之后在@When中模拟在另一台机器上启动一个Node加入到集群的过程。因为实际上这个过程是在远程完成的，所以不能直接使用成员变量cluster。最后验证cluster中的结点列表，看是否已经包含两个结点。
public class MyStepdefs {
private Cluster cluster;
@Given("^node-(\w+) in cluster-(\w+) starts$")
public void runCluster(String nodeId, String clusterName) {
Node node = new Node(nodeId);
cluster = new Cluster(clusterName, new CoordinatorMock());
node.join(cluster);
}
@When("^a new node-(\w+) in cluster-(\w+) starts$")
public void startNewNodeToJoinCluster(String nodeId, String clusterName) {
Node newNode = new Node(nodeId);
Cluster clusterSlave = new Cluster(clusterName, new CoordinatorMock());
newNode.join(clusterSlave);
}
@Then("^cluster-(\w+) should have node: (.+)$")
public void joinCluster(String clusterName, List<String> nodeIds) {
Assert.assertEquals(clusterName, cluster.getName());
List<String> actualNodeIds = new ArrayList<String>();
for (Node node : cluster.getNodes()) {
actualNodeIds.add(node.getId());
}
Collections.sort(actualNodeIds);
Assert.assertEquals(nodeIds, actualNodeIds);
}
}对比下面典型的单元测试代码能够看出，BDD的Steps代码因为对应着Scenario，所以步骤分的比较清楚。而在普通Test Case中，Case中就会堆砌着类似@Given、@When、@Then的代码，并且每个Case都会有类似的代码。所以一般我们会提取出一些公关的代码，以使Case更为清晰，但BDD则直接更进一步。
@Test
public void testCachePut2_List() throws Exception {
CacheResult<Object> ret = redis.cachePut(CACHE_NAME,
Arrays.asList(
new Person(1, 49, "alan"),
new Person(2, 34, "hank"),
new Person(3, 38, "carter")
)
);
Assert.assertTrue(ret.isOK());
List persons = redis.cacheGetAll(CACHE_NAME, Arrays.asList(1, 3)).getValue();
Collections.sort(persons);
Assert.assertNotNull(persons);
Assert.assertEquals(2, persons.size());
...
}4.实战(下)：核心类进化
下面就说一下通过这次BDD历险得到的核心类，以及是如何思考出来的。这个重构、思考、最终浮现出来的过程其实是最重要的！
最先映入脑海的就是Cluster和Node，其实Node也可以暂时用一个ID代替，之后有需要时再抽象成类，这里有些“着急”了直接新建了个Node类。
public class Cluster {
private final String name;
private List<Node> nodes = new ArrayList<Node>();
public Cluster(String name) {
this.name = name;
}
public void addNode(Node node) {
}
public String getName() {
return name;
}
public List<Node> getNodes() {
return nodes;
}
}
public class Node {
private String nodeId;
public Node(String nodeId) {
this.nodeId = nodeId;
}
public void join(Cluster cluster) {
cluster.addNode(this);
}
public String getId() {
return nodeId;
}
}写好了@Given、@When、@Then之后，就可以跑起来Cucumber试试了，肯定是报错的。现在自然就有疑问了，@Then中的断言如何能够成功呢？所以Cluster背后需要一个能够帮助分布式通信的组件，于是就加上Coordinator接口。同时，我们创建一个Mock实现，利用static静态变量模拟网络通信的过程。
public interface Coordinator {
void register(Cluster cluster);
boolean addNode(Node node);
}
public class CoordinatorMock implements Coordinator {
/** Simulate network communication */
private static List<Cluster> clusters = new ArrayList<Cluster>();
@Override
public void register(Cluster cluster) {
clusters.add(cluster);
}
@Override
public boolean addNode(Node node) {
for (Cluster cluster : clusters) {
cluster.handleAddNode(node);
}
return true;
}
}最后让Cluster注册到Coordinator上，调用addNode()接口模拟分布式通信，并添加handleAddNode()处理请求就可以了！这样我们就完成了BDD的一个简单实例！
public class Cluster {
private final String name;
private final Coordinator coordinator;
private List<Node> nodes = new ArrayList<Node>();
public Cluster(String name, Coordinator coordinator) {
this.name = name;
this.coordinator = coordinator;
coordinator.register(this);
}
public void addNode(Node node) {
coordinator.addNode(node);
}
public void handleAddNode(Node node) {
nodes.add(node);
}
public String getName() {
return name;
}
public List<Node> getNodes() {
return nodes;
}
}5.总结
每种新事物的产生都不可避免地会伴随着各种各样的解读，毕竟每个人都有自己的看法和理解。有的理解深刻直达本质，有的独辟蹊径另立门派，也有的是偏见和误解。BDD也一样，可能会人被当做跟TDD一样的东西，也可能会被看做测试的一种。
通过本文的介绍，大家应该能看到BDD的闪光点。它提升了TDD的粒度和抽象层次，并以统一而规范的语言作为文档，消除了软件开发中各种人员的沟通障碍。同时以实用的框架将文档与代码粘合到一起，使文档可执行化、代码文档化。