测试断言，网络客户端只被调用了一次，第一次使用之后网络stub就简单地抛出错误。这里有一个小问题，因为测试是人工控制待测对象断言。比如，如果待测系统将要多次调用网络stub的send函数，而它自己处理抛出的异常，那么测试永远也不会失败，因为test runner永远也不会收到任何出问题的通知。一个解决方法是创建更精致的微型mocking框架，但是通用的诸如JsMock这样的方法通常更简单。
JsMock不仅仅能够让我们测试方法调用顺序和参数值。这个测试演示老虎机在网络发生故障时的行为。
|
function testGetBalanceWithFailure(){
var slotMachine = new drw.SlotMachine(buttonStub, null, null, null, networkMock); slotMachine.getBalance(); assertEquals('Sorry, can't talk to the server right now', buttonStub.value); } |
这里我们验证老虎机在网络发生故障时可以优雅地失败。这是单元测试能够胜过系统集成测试的一个很好的例子。您能想像每个QA/发布周期中，对服务器每个集成点手工模拟一个网络故障花费的时间和金钱吗？
getBalance方法的实现现在看上去是这样的：
| drw.SlotMachine.prototype.getBalance = function() { if(this.balanceRequested) return; try{ // this line of code requires the very excellent functional.js // library, found at http://osteele.com/sources/javascript/functional this.networkClient.send('/getBalance.jsp', this.deposit.bind(this)); this.balanceRequested = true; }catch(e){ this.buttonElement.value = 'Sorry, can't talk to the server right now'; } }; |
与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方法：
| var depositCallback; networkMock.expects() .send('/getBalance.jsp', TypeOf.isA(Function)) .andStub( function(){depositCallback = arguments[1];} ); depositCallback({responseText:"10"}); |
