测试断言，网络客户端只被调用了一次，第一次使用之后网络stub就简单地抛出错误。这里有一个小问题，因为测试是人工控制待测对象断言。比如，如果待测系统将要多次调用网络stub的send函数，而它自己处理抛出的异常，那么测试永远也不会失败，因为test runner永远也不会收到任何出问题的通知。一个解决方法是创建更精致的微型mocking框架，但是通用的诸如JsMock这样的方法通常更简单。
JsMock不仅仅能够让我们测试方法调用顺序和参数值。这个测试演示老虎机在网络发生故障时的行为。
2
3 var buttonStub = {};
4
5 var mockControl = new MockControl();
6
7 var networkMock = mockControl.createMock({
8
9 send : function() {}
10
11 });
12
13 networkMock.expects()
14
15 .send('/getBalance.jsp', TypeOf.isA(Function))
16
17 .andThrow('network failure');
18
19 var slotMachine = new drw.SlotMachine(buttonStub, null, null, null, networkMock);
20
21 slotMachine.getBalance();
22
23 assertEquals('Sorry, can't talk to the server right now', buttonStub.value);
24
25 mockControl.verify();
26
27 }
28
这里我们验证老虎机在网络发生故障时可以优雅地失败。这是单元测试能够胜过系统集成测试的一个很好的例子。您能想像每个QA/发布周期中，对服务器每个集成点手工模拟一个网络故障花费的时间和金钱吗?
getBalance方法的实现现在看上去是这样的：
2
3 if(this.balanceRequested)
4
5 return;
6
7 try{
8
9 // this line of code requires the very excellent functional.js
10
11 // library, found at http://osteele.com/sources/javascript/functional
12
13 this.networkClient.send('/getBalance.jsp', this.deposit.bind(this));
14
15 this.balanceRequested = true;
16
17 }catch(e){
18
19 this.buttonElement.value = 'Sorry, can't talk to the server right now';
20
21 }
22
23 };
24
与stub相比，mock的一个缺点是和被测系统的耦合相当多，至少希望拿来就用。当被测系统的行为与期望不符时，你希望测试失败──你并不希望被封装的实现细节有任何变化时，测试就会失败。为了弥补这种情况，JsMock提供了放宽期望的能力。其实你已经看到了这个例子。当我们准备网络mock对象时，这样写的：
networkMock.expects().send('/getBalance.jsp', TypeOf.isA(Function));
我们并没有指定哪个回调函数会被用作第二个参数，只需要是一个回调函数就可以了。如果我们想把这些期望放的更宽些，我们可以这样尝试：
networkMock.expects().send(TypeOf.isA(String), TypeOf.isA(Function));
如果我们想引用网络客户端mock的send方法的实际回调函数，我们可以使用JsMock框架的andStub方法：
2
3 networkMock.expects()
4
5 .send('/getBalance.jsp', TypeOf.isA(Function))
6
7 .andStub( function(){depositCallback = arguments[1];} );
8
9 depositCallback({responseText:"10"});
在我们继续之前，关于mock对象有两点需要知道。注意到每个测试最后如何调用MockControl的verify方法。这很重要。单元测试不调用verify方法就不会失败。许多开发者遇到过这样的事情，写了一些标准的单元测试函数之后，就认为把对verify方法从测试函数移到tearDown函数更好。虽然这会节省几行代码，也让你不必在每个测试函数的最后都去记住这一重要细节，不幸的是，它会给你带来一个新问题：tearDown中抛出的异常会被测试中抛出的第一个异常掩盖。第二个陷阱是新手经常过度使用mock对象，并用它们完全替代stub。不要这样。用stub来做基于状态的测试，使用mock做基于交互的测试。
