Adding Behavior

　　public void testAddDocument() { mock.documentAdded(“New Document“); // 2 replay(mock); // 3 classUnderTest.addDocument(“New Document“, new byte[0]); }

　　Specifying Return Values

　　public void testVoteForRemoval() { mock.documentAdded(“Document“); // expect document addition // expect to be asked to vote for document removal, and vote for it expect(mock.voteForRemoval(“Document“)).andReturn((byte) 42); mock.documentRemoved(“Document“); // expect document removal replay(mock); classUnderTest.addDocument(“Document“, new byte[0]); assertTrue(classUnderTest.removeDocument(“Document“)); verify(mock);}

　　什么是Mock Server

　　前面说了好多什么是Mock，或者说什么是Mock Object，那什么是Mock Server呢？其实它相对于我们一直使用的桩程序来说的，为了方便，下文将其称为Stub Server。

　　MockServer的工作原理

　　一般桩程序的结构

　　首先，我们先回顾一下以往的Stub Server是什么样的

　　Stub Server，作为一个模拟下游模块的行为的程序，它的功能无非两方面，一个是接受请求，一个是返回结果。当然为测试的便利，在返回结果时可能还会有一些简单的逻辑，比如填充一些无关字段。

　　对于一个标准的Stub Server，它的结构通常是：

　　创建SOCKET，监听所需的端口WHILE NOT STOP: 从socket中读数据 IF 数据满足[条件] THEN 返回[结果数据] END IFEND WHILE

　　为了适应的不同的被测系统，Stub Server需要跟据情况实现不同的接口协议，对数据包进行解析和封装，这部分的工作量占据了很大一部分比重，且实际代码往往单调繁琐。 这个问题可以利用一些代码自动生成技术或接口定义语言来解决，这方面的话题不在本文中讨论了。

　　接口实现好了，接下就是跟据需要来返回相应的数据了，对应于前面的流程，其实就是替换其中的[条件]和[结果数据]，以适应不同的CASE。那么如何描述 [条件]和[结果数据]自然也就是成了接下来要解决的问题，有时我们会直接将它们硬编码到程序里，或者使用配置文件来描述[条件]和[结果数据]以触发程序中不同的处理代码。如果数据的结构比较简单，这种方法是很好实现的，但如果数据结构比较复杂，那配置文件格式的设计与数据的解析加载都会是件很烦人的事情，而如果想在配置中添加一些简单的逻辑以使程序有更大的灵活性，则更是一件烦上加烦的事情。

　　MockServer的结构

　　MockServer的设计思想在于将接口的操作和数据的操作分离，在实现桩程序时，只考虑对各种通信接口的包装，而将[条件]和[结果数据]的构造交给使用者。这样，同样一个桩程序，只要是基于相同的通信协议，就可以模拟出任意的行为，就像mock对象可以模拟任意对象的行为一样。

　　比如一个基于socket的Mock Server的可以描述为：

　　创建SOCKET，监听所需的端口WHILE NOT STOP: 从socket中读数据 执行[MOCK行为] END IFEND WHILE

　　其中MOCK行为可能是这样描述的：

　　ON: recieve(‘HELLO‘)DO: sendback(‘WORLD‘) keep_alive()ON: recieve(‘QUIT‘)DO: close_link()

　　可见，Mock Server的核心就是如果实现执行[MOCK行为]