追求代码质量: 亲身体验行为驱动开发

核心提示： 行为驱动开发清单 6 中的输出与 JUnit 的输出是不是很像？这也许不是巧合，对不对？如前所述，追求代码质量: 亲身体验行为驱动开发(5)，JBehave 是根据 xUnit 范例建模的，它甚至通过 setUp() 和 tearDown() 提供了对 fixture 的支持，但是，在开始编写

行为驱动开发

清单 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() 之前，让我们考虑一些事情。

确保行为