测试驱动的开发（TDD）在实践中是一个很好的思想，但有些开发人员还不能接受 “测试” 这个词所产生的概念上的骤变。在本文中，学习一种更自然的方法，将 TDD 元素整合到编程实践中。开始采用行为驱动开发（BDD）（通过 JBehave），亲身体验将注意力集中在程序行为（而不是输出）时获得的效果。
显然，测试本身是件好事。而在早期进行测试 — 例如在编写代码时 — 则更有益处，这特别有利于提高代码质量。在开发早期编写测试，您将获益良多。您能够检查代码的行为，并预先对它进行调试，这种动力无疑是巨大的。
即使了解了这种重要性，我们也没有达到关键的一点：使在编写代码之前 编写测试成为一种标准实践。正如 TDD 是极限编程（Extreme Programming）的下一个演化阶段（后者推出了单元测试框架），以 TDD 为基础，新的飞跃也将到来。本月，我邀请您和我一起实现从 TDD 到更具直观性的行为驱动测试（BDD）的演化。
行为驱动开发
虽然测试优先编程对于有些人比较管用，但是并不适用于每一个人。虽然有的应用程序开发人员狂热拥护 TDD，但也有人坚决抵制它。即使现在已经有了很多测试框架，例如 TestNG、 Selenium 和 FEST，但不对 代码进行测试的理由仍然充分。
不采用 TDD 的两个常见理由是 “没有足够的时间进行测试” 和 “代码太复杂，难以测试”。测试优先编程的另一个障碍是测试优先概念本身。很多人把测试看作一种反应型活动，仅比抽象具体一点。经验告诉我们，不能测试不存在的东西。对于某些开发人员来说，对于这种概念框架，测试优先 是一种矛盾的说法。
但是，如果不考虑编写测试和如何测试，而是考虑行为，结果会如何呢？这里所说的行为，是指一个应用程序应该 如何运行 — 实际上就是指它的规范。
实际上，您已经想到了这种方法。我们都想到过。请看下面的对话。
Frank: 什么是栈？
Linda: 它是一种数据结构，按先进后出（或后进先出）的方式收集对象。它通常有一个 API，其中包括 push() 和 pop() 等方法。有时也有 peek() 方法。
Frank: push() 有什么功能？
Linda: push() 接受一个输入对象，比如说 foo，并将它放入到一个内部容器（例如一个数组）中。push() 通常不返回结果。
Frank: 如果我 push() 两个对象，比如先是 foo，然后是 bar，结果会怎样？
Linda: 第二个对象 bar 应该在栈（至少包含两个对象）的顶部，所以如果调用 pop()，那么返回的应该是 bar，而不是 foo。如果再次调用 pop()，那么应该返回 foo，然后栈为空（假设在添加这两个对象之前栈中没有对象）。
Frank: 也就是说，pop 移除最近放入栈中的项目？
Linda: 是的，pop() 应该移除最上面的项目（假设栈中还有可移除的项目）。peek() 与此类似，只是不移除栈中的对象。peek() 应该保留栈顶的项目。
Frank: 如果之前没有 push 任何项目，那么调用 pop() 时会怎样？
Linda: pop() 应该抛出一个异常，表明栈中尚未 push 任何项。
Frank: 如果 push() null 会怎样？
Linda: 栈应该抛出一个异常，因为 null 不是一个有效的可 push() 的值。
在这段对话中，有没有注意到什么特别的地方呢（除了 Frank 不是计算机科学专业的）？这里从头到尾没有用到 “测试” 这个词。但是，“应该” 这个词却非常自然地随处闪现。
怎么做才自然？
BDD 并不是什么新生事物，更不具备什么革命性的突破。它只是 TDD 的一个分支，其中 “测试” 这个词换成了 “应该”。除了语义，很多人还发现，与测试 概念相比，应该 这个概念是一种更自然的开发驱动因素。考虑行为（应该）会自然而然地促使您先编写规范类，而后者可以成为一个非常有效的实现驱动因素。
以 Frank 和 Linda 的对话为基础，让我们看看 BDD 如何以 TDD 希望推广的方式驱动开发。
JBehave
JBehave 是用于 Java™ 平台的一个 BDD 框架，源于 xUnit 范例。正如您所料，JBehave 强调应该 这个词，而不是测试。和 JUnit 一样，您可以在自己喜欢的 IDE 中，或者通过偏爱的构建平台（例如 Ant）运行 JBehave 类。
JBehave 允许以 JUnit 的方式创建行为类；但是，在 JBehave 中，不需要扩展任何特定的基类，并且所有行为方法都需要以 should 而不是 test 开头，如清单 1 所示。
清单 1. 用于栈的一个简单的行为类
public class StackBehavior {
public void shouldThrowExceptionUponNullPush() throws Exception{}
public void shouldThrowExceptionUponPopWithoutPush() throws Exception{}
public void shouldPopPushedValue() throws Exception{}
public void shouldPopSecondPushedValueFirst() throws Exception{}
public void shouldLeaveValueOnStackAfterPeep() throws Exception{}
}
清单 1 中定义的方法都是以应该开头，它们都创建一个人类可读的句子。这里产生的 StackBehavior 类描述 Frank 和 Linda 之间的对话中提到的栈的很多特性。
例如，Linda 说，如果用户试图将 null 放到栈上，那么栈应该 抛出一个异常。查看 StackBehavior 类中的第一个行为方法：该方法的方法名为 shouldThrowExceptionUponNullPush()。其它方法的命名也遵从这一模式。这种描述性命名模式（这并不是 JBehave 或 BDD 特有的）便于以人类可读的方式报告失败行为，您很快就可以看到这一点。
说到 shouldThrowExceptionUponNullPush()，那么如何验证这个行为呢？似乎 Stack 类首先需要有一个 push() 方法，这很容易定义。
清单 2. 用于探索行为的一个简单的栈定义
public class Stack＜E＞ {
public void push(E value) {}
}
可以看到，我编写了一个最简单的栈，以便首先 添加必需的行为。正如 Linda 所说，行为很简单：如果有人对 null 值调用 push()，那么栈应该 抛出一个异常。现在看看我在清单 3 中如何定义这个行为。
清单 3. 如果推出一个 null 值，则栈应该抛出一个异常
public void shouldThrowExceptionUponNullPush() throws Exception{
final Stack＜String＞ stStack = new Stack＜String＞();
Ensure.throwsException(RuntimeException.class, new Block(){
public void run() throws Exception {
stStack.push(null);
}
});
}
杰出的 expectation 和 override
在清单 3 中发生的一些事情是 JBhave 特有的，所以要解释一下。首先，我创建 Stack 类的一个实例，并将它限制为 String 类型（通过 Java 5 泛型）。接下来，我使用 JBehave 的 异常框架 实际建模我所期望的行为。 Ensure 类类似于 JUnit 或 TestNG 的 Assert 类型；但是，它增加了一系列方法，提供了更具可读性的 API（这常被称作文学编程）。在清单 3 中，我确保了如果对 null 调用 push()，则抛出一个 RuntimeException。
JBehave 还引入了一个 Block 类型，它是通过用所需的行为覆盖 run() 方法来实现的。在内部，JBehave 确保期望的异常类型不被抛出（并因此被捕捉），而是生成一个故障状态。您可能还记得，在我前面关于 用 Google Web Toolkit 对 Ajax 进行单元测试 的文章中，也出现了类似的覆盖便利类的模式。在那种情况下，覆盖是通过 GWT 的 Timer 类实现的。
如果现在运行清单 3 中的行为，应该看到出现错误。按照目前编写的代码，push() 方法不执行任何操作。所以不可能生成异常，从清单 4 中的输出可以看到这一点。
清单 4. 没有发生期望的行为
1) StackBehavior should throw exception upon null push:
VerificationException: Expected:
object not null
but got:
null:
清单 4 中的句子 “StackBehavior should throw exception upon null push” 模拟行为的名称（shouldThrowExceptionUponNullPush()），并加上类的名称。 实际上，JBehave 是在报告当它运行所需的行为时，没有获得任何反应。当然，我的下一步是要使上述行为成功运行，为此我检查 null，如清单 5 所示。
清单 5. 在栈类中增加指定的行为
public void push(E value) {
if(value == null){
throw new RuntimeException("Can't push null");
}
}
当我重新运行行为时，一切都运行得很好，如清单 6 所示。
清单 6. 成功！
Time: 0.021s
Total: 1. Success!
行为驱动开发
清单 6 中的输出与 JUnit 的输出是不是很像？这也许不是巧合，对不对？如前所述，JBehave 是根据 xUnit 范例建模的，它甚至通过 setUp() 和 tearDown() 提供了对 fixture 的支持。由于我可能在整个行为类中使用一个 Stack 实例，我可能也会将那种逻辑推入（这里并非有意使用双关语）到一个 fixture 中，正如清单 7 中那样。注意， JBehave 将与 JUnit 一样遵循相同的 fixture 规则 — 也就是说，对于每个行为方法，它都运行一个 setUp() 和 tearDown()。
清单 7. JBehave 中的 fixture
public class StackBehavior {
private Stack＜String＞ stStack;
public void setUp() {
this.stStack = new Stack＜String＞();
}
//...
}
对于接下来的行为方法，shouldThrowExceptionUponPopWithoutPush() 表示我必须确保它具有类似于 清单 3 中的 shouldThrowExceptionUponNullPush() 的行为。从清单 8 中可以看出，没有任何特别神奇的地方 — 有吗？
清单 8. 确保 pop 的行为
public void shouldThrowExceptionUponPopWithoutPush() throws Exception{
Ensure.throwsException(RuntimeException.class, new Block() {
public void run() throws Exception {
stStack.pop();
}
});
}
您可能已经清楚地知道，此时清单 8 并不会真正地编译，因为 pop() 还没有被编写。但是，在开始编写 pop() 之前，让我们考虑一些事情。
确保行为
从技术上讲，在这里我可以将 pop() 实现为无论调用顺序如何，都只抛出一个异常。但是当我沿着这条行为路线前进时，我又忍不住考虑一个支持我所需要的规范的实现。在这种情况下，如果 push() 没有被调用（或者从逻辑上讲，栈为空）的情况下确保 pop() 抛出一个异常，则意味着栈有一个状态。正如之前 Linda 思考的那样，栈通常有一个 “内部容器”，用于实际持有项目。相应地，我可以为 Stack 类创建一个 ArrayList，用于保持传递给 push() 方法的值，如清单 9 所示。
清单 9. 栈需要一种内部的方式来持有对象
public class Stack＜E＞ {
private ArrayList＜E＞ list;
public Stack() {
this.list = new ArrayList＜E＞();
}
//...
}
现在我可以为 pop() 方法编写行为，即确保当栈在逻辑上为空时，抛出一个异常。
清单 10. pop 的实现变得更容易
public E pop() {
if(this.list.size() ＞ 0){
return null;
}else{
throw new RuntimeException("nothing to pop");
}
}
当我运行清单 8 中的行为时，一切如预期运行：由于栈中没有存在任何值（因此它的大小不大于 0），于是抛出一个异常。
接下来的行为方法是 shouldPopPushedValue()，这个行为方法很容易指定。我只是 push() 一个值（“test”），并确保当调用 pop() 时，返回相同的值。
清单 11. 如果将一个值入栈，那么出栈的也应该是它，对吗？
public void shouldPopPushedValue() throws Exception{
stStack.push("test");
Ensure.that(stStack.pop(), m.is("test"));
}
为 Matcher 挑选 ‘M’
在清单 11 中，我确保 pop() 返回值 “test”。在使用 JBehave 的 Ensure 类的过程中，您常常会发现，需要一种更丰富的方式来表达期望。JBehave 提供了一种 Matcher 类型用于实现丰富的期望，从而满足了这一需求。而我选择重用 JBehave 的 UsingMatchers 类型（清单 11 中的 m 变量），所以可以使用 is()、and()、or() 等方法和很多其它整洁的机制来构建更具文学性的期望。
清单 11 中的 m 变量是 StackBehavior 类的一个静态成员，如清单 12 所示。
清单 12. 行为类中的 UsingMatchers
private static final UsingMatchers m = new UsingMatchers(){};
有了清单 11 中编写的新的行为方法之后，现在可以来运行它 — 但是这时会产生一个错误，如清单 13 所示。
清单 13. 新编写的行为不能运行
Failures: 1.
1) StackBehavior should pop pushed value:
java.lang.RuntimeException: nothing to pop
怎么回事？原来是我的 push() 方法还没有完工。回到 清单 5，我编写了一个最简单的实现，以使我的行为可以运行。现在是时候完成这项工作了，即真正将被推入的值添加到内部容器中（如果这个值不为 null）。如清单 14 所示。
清单 14. 完成 push 方法
public void push(E value) {
if(value == null){
throw new RuntimeException("Can't push null");
}else{
this.list.add(value);
}
}
但是，等一下 — 当我重新运行该行为时，它仍然失败！
清单 15. JBehave 报告一个 null 值，而不是一个异常
1) StackBehavior should pop pushed value:
VerificationException: Expected:
same instance as ＜test＞
but got:
null:
至少清单 15 中的失败有别于清单 13 中的失败。在这种情况下，不是抛出一个异常，而是没有发现 "test" 值；实际弹出的是 null。仔细观察 清单 10 会发现：一开始我将 pop() 方法编写为当内部容器中有项目时，就返回 null。问题很容易修复。
清单 16. 是时候编写完这个 pop 方法了
public E pop() {
if(this.list.size() ＞ 0){
return this.list.remove(this.list.size());
}else{
throw new RuntimeException("nothing to pop");
}
}
但是，如果现在我重新运行该行为，我又收到一个新的错误。
清单 17. 另一个错误
1) StackBehavior should pop pushed value:
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
仔细阅读清单 17 中的实现可以发现问题：在处理 ArrayList 时，我需要考虑 0。
清单 18. 通过考虑 0 修复问题
public E pop() {
if(this.list.size() ＞ 0){
return this.list.remove(this.list.size()-1);
}else{
throw new RuntimeException("Nothing to pop");
}
}
栈的逻辑
至此，通过允许传递多个行为方法，我已经实现了 push() 和 pop() 方法。但是我还没有处理栈的实际内容，这是与多个 push() 和 pop() 相关联的逻辑，间或出现一个 peek()。
首先，我将通过 shouldPopSecondPushedValueFirst() 行为确保栈的基本算法（先进先出）无误。
清单 19. 确保典型的栈逻辑
public void shouldPopSecondPushedValueFirst() throws Exception{
stStack.push("test 1");
stStack.push("test 2");
Ensure.that(stStack.pop(), m.is("test 2"));
}
清单 19 中的代码可以按计划运行，所以我将实现另一个行为方法（在清单 20 中），以确保两次使用 pop() 都能表现出正确的行为。
清单 20. 更深入地查看栈行为
public void shouldPopValuesInReverseOrder() throws Exception{
stStack.push("test 1");
stStack.push("test 2");
Ensure.that(stStack.pop(), m.is("test 2"));
Ensure.that(stStack.pop(), m.is("test 1"));
}
接下来，我要确保 peek() 能按预期运行。正如 Linda 所说，peek() 遵从和 pop() 相同的规则，但是 “应该保留栈顶的项目”。相应地，我在清单 21 中实现了 shouldLeaveValueOnStackAfterPeep() 方法的行为。
清单 21. 确保 peek 保留栈顶的项目
public void shouldLeaveValueOnStackAfterPeep() throws Exception{
stStack.push("test 1");
stStack.push("test 2");
Ensure.that(stStack.peek(), m.is("test 2"));
Ensure.that(stStack.pop(), m.is("test 2"));
}
由于 peek() 还没有定义，因此清单 21 还不能编译。在清单 22 中，我定义了 peek() 的一个最简单的实现。
清单 22. 当前，peek 是必需的
public E peek() {
return null;
}
现在 StackBehavior 类可以编译，但是它仍然不能运行。
清单 23. 返回 null 并不奇怪，对吗？
1) StackBehavior should leave value on stack after peep:
VerificationException: Expected:
same instance as ＜test 2＞
but got:
null:
在逻辑上，peek() 不会从内部集合中移除 项目，它只是传递指向那个项目的指针。因此，我将对 ArrayList 使用 get() 方法，而不是 remove() 方法，如清单 24 所示。
清单 24. 不要移除它
public E peek() {
return this.list.get(this.list.size()-1);
}
栈为空的情况
现在重新运行 清单 21 中的行为，结果顺利通过。但是，在这样做的过程中发现一个问题：如果栈为空，则 peek() 有怎样的行为？如果说栈为空时调用 pop() 会抛出一个异常，那么 peek() 是否也应该如此？
Linda 对此没有进行解释，所以，显然我需要自己添加新的行为。在清单 25 中，我为 “当之前没有调用 push() 时调用 peek() 会怎样” 这个场景编写了代码。
清单 25. 如果没有调用 push 就调用 peek，会怎样？
public void shouldReturnNullOnPeekWithoutPush() throws Exception{
Ensure.that(stStack.peek(), m.is(null));
}
同样，不会感到意外。如清单 26 所示，问题出现了。
清单 26. 没有可执行的内容
1) StackBehavior should return null on peek without push:
java.lang.ArrayIndexOutOfBoundsException: -1
修复这个缺陷的逻辑类似于 pop() 的逻辑，如清单 27 所示。
清单 27. 这个 peek() 需要做一些修复
public E peek() {
if(this.list.size() ＞ 0){
return this.list.get(this.list.size()-1);
}else{
return null;
}
}
把我对 Stack 类作出的所有修改和修复综合起来，可以得到清单 28 中的代码。
清单 28. 一个可正常工作的栈
import java.util.ArrayList;
public class Stack＜E＞ {
private ArrayList＜E＞ list;
public Stack() {
this.list = new ArrayList＜E＞();
}
public void push(E value) {
if(value == null){
throw new RuntimeException("Can't push null");
}else{
this.list.add(value);
}
}
public E pop() {
if(this.list.size() ＞ 0){
return this.list.remove(this.list.size()-1);
}else{
throw new RuntimeException("Nothing to pop");
}
}
public E peek() {
if(this.list.size() ＞ 0){
return this.list.get(this.list.size()-1);
}else{
return null;
}
}
}
在此，StackBehavior 类运行 7 种行为，以确保 Stack 类能按照 Linda 的（和我自己的一点）规范运行。Stack 类 还可能使用某种重构（也许 pop() 方法 应该调用 peek() 进行测试，而不是执行 size() 检查？），但是由于一直使用了行为驱动过程，我可以很自信地对代码作出更改。如果出现了问题，很快就可以收到通知。
结束语
您可能已经注意到，本月对行为驱动开发（BDD）的探索中，Linda 实际上就是客户。在这里，可以把 Frank 看作开发人员。如果把这里的领域（即数据结构）换成其它领域（例如一个呼叫中心应用程序），以上应用仍然类似。作为客户或领域专家的 Linda 指出系统、特性或应用程序应该 执行什么功能，像 Frank 这样的开发人员则使用 BDD 确保正确理解了她的要求并实现这些需求。
对于很多开发人员来说，从测试驱动开发转移到 BDD 是明智的转变。 如果采用 BDD，就不必考虑测试，而只需注意应用程序的需求，并确保应用程序的行为执行它 应该 执行的功能，以满足那些需求。
在这个例子中，使用 BDD 和 JBehave 使我可以根据 Linda 的说明轻松地实现一个可正常工作的栈。通过首先 考虑行为，我只需倾听她的需求，然后相应地构建栈。在此过程中，我还发现了 Linda 没有提及的关于栈的其他内容。
关于作者
Andrew Glover 是 Stelligent Incorporated 的总裁，这家公司用有效的开发人员测试策略和能够让团队在早期经常地监视代码质量的持续集成技术，帮助企业解决软件质量问题。请访问 Andy 的博客，查看他已出版作品的列表。
文章来源于领测软件测试网 https://www.ltesting.net/
