为 Matcher 挑选 ‘M’关于 UsingMatchers 类型您可能注意到， 中的代码并不是很优雅。清单 11 中的 m 确实有点影响代码的可读性（“ensure that pop's value m (what the?) is test）。可以通过扩展 JBehave 提供的一个专门的基类（UsingMiniMock）来避免使用 UsingMatchers 类型。这样一来，清单 11 中最后一行就变成 Ensure.that(stStack.pop(), is("test"))，这样可读性更好一点。
在清单 11 中，我确保 pop() 返回值 “test”。在使用 JBehave 的 Ensure 类的过程中，您常常会发现，需要一种更丰富的方式来表达期望。JBehave 提供了一种 Matcher 类型用于实现丰富的期望，从而满足了这一需求。而我选择重用 JBehave 的 UsingMatchers 类型（清单 11 中的 m 变量），所以可以使用 is()、and()、or() 等方法和很多其它整洁的机制来构建更具文学性的期望。
清单 11 中的 m 变量是 StackBehavior 类的一个静态成员，如清单 12 所示。
清单 12. 行为类中的 UsingMatchers1
| private static final UsingMatchers m = new UsingMatchers(){};
|
有了清单 11 中编写的新的行为方法之后，现在可以来运行它 — 但是这时会产生一个错误，如清单 13 所示。
清单 13. 新编写的行为不能运行1
2
3
4
| Failures: 1.
1) StackBehavior should pop pushed value:
java.lang.RuntimeException: nothing to pop
|
怎么回事？原来是我的 push() 方法还没有完工。回到 ，我编写了一个最简单的实现，以使我的行为可以运行。现在是时候完成这项工作了，即真正将被推入的值添加到内部容器中（如果这个值不为 null）。如清单 14 所示。
清单 14. 完成 push 方法1
2
3
4
5
6
7
| public void push(E value) {
if(value == null){
throw new RuntimeException("Can't push null");
}else{
this.list.add(value);
}
}
|
但是，等一下 — 当我重新运行该行为时，它仍然失败！
清单 15. JBehave 报告一个 null 值，而不是一个异常1
2
3
4
5
| 1) StackBehavior should pop pushed value:
VerificationException: Expected:
same instance as <test>
but got:
null:
|
至少清单 15 中的失败有别于清单 13 中的失败。在这种情况下，不是抛出一个异常，而是没有发现 "test" 值；实际弹出的是 null。仔细观察 会发现：一开始我将 pop() 方法编写为当内部容器中有项目时，就返回 null。问题很容易修复。
清单 16. 是时候编写完这个 pop 方法了1
2
3
4
5
6
7
| public E pop() {
if(this.list.size() > 0){
return this.list.remove(this.list.size());
}else{
throw new RuntimeException("nothing to pop");
}
}
|
但是，如果现在我重新运行该行为，我又收到一个新的错误。
清单 17. 另一个错误1
2
| 1) StackBehavior should pop pushed value:
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
|
仔细阅读清单 17 中的实现可以发现问题：在处理 ArrayList 时，我需要考虑 0。
清单 18. 通过考虑 0 修复问题1
2
3
4
5
6
7
| public E pop() {
if(this.list.size() > 0){
return this.list.remove(this.list.size()-1);
}else{
throw new RuntimeException("Nothing to pop");
}
}
|
|
