最近抽空翻译了一下manning出版的junit in action,译的比候捷还糟，大家不要bt.
以下是第7章的内容
第一节 mock object 的介绍：
隔离测试有很多好处，比如测试那些还没有写出来的代码（只要他有个接口）。另外，隔离测试有利于工作团队对代码的一部分进行测试而不用等到所有的部分都开发完毕。
但是，可能最大的 好处就是能够写出相关的测试来测试单个方法，而避免其他被调用对象产生副作用.
MockObject很好的解决了隔离测试问题。Mocks替换了那些对象（你的方法需要调用的），因此产生了一个隔离层 ,从这个角度来看，他和stubs很相似。但是，这是他们唯一的相似点。因为mocks没有实现任何的逻辑（logic）:他们只是空壳---提供途径让测试 控制 伪造类的所有商业方法的表现。
下面是mock object 的定义：
mock object是一个被用来代替在你程序中被调用的对象的对象。你的代码可以调用mockobject的对象，他产生的结果和你的真实环境中是一样的。
第二节 一个简单的例子：
AccountService为商业逻辑。
AccountManager相当于facade,提供对数据库的存取。
Account的功能相当于vo。
在没有mocks的情况下，测试AccountService---transfer这个行为将要建立一个数据库，预置一些测试数据，而且还需要部署你的代码到应用服务器（container）等等。尽管这些过程需要在你的应用程序中都要被一一用到，但是对于测试代码逻辑来说他做了太多不必要的工作。
这个例子的结构示意图如下：
Account.java
package junitbook.fine.tasting;<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
public class Account
{
private String accountId;
private long balance;
public Account(String accountId, long initialBalance)
{
this.accountId = accountId;
this.balance = initialBalance;
}
public void debit(long amount)
{
this.balance -= amount;
}
public void credit(long amount)
{
this.balance += amount;
}
public long getBalance()
{
return this.balance;
}
}
产生简单的account对象，他有两个属性：ID,balance.
AccountManager.java
package junitbook.fine.tasting;
public interface AccountManager
{
Account findAccountForUser(String userId);
void updateAccount(Account account);
}
一个接口。用来控制account对象。有两个方法。
AccountService.java
package junitbook.fine.tasting;
public class AccountService
{
private AccountManager accountManager;
public void setAccountManager(AccountManager manager)
{
this.accountManager = manager;
}
public void transfer(String senderId, String beneficiaryId,
long amount)
{
Account sender =
this.accountManager.findAccountForUser(senderId);
Account beneficiary =
this.accountManager.findAccountForUser(beneficiaryId);
sender.debit(amount);
beneficiary.credit(amount);
this.accountManager.updateAccount(sender);
this.accountManager.updateAccount(beneficiary);
}
}
提供了在账户之间转换金钱的方法。他使用了你先前定义的AccountManager接口来获得account对象并对他进行操作。
想要测试AccountService.transfer方法。你需要一个mock对象实现AccountManager接口。这样做的原因是因为你的transfer方法使用了这个接口，但是你需要隔离测试。
MockAccountManager.java
package junitbook.fine.tasting;
import java.util.Hashtable;
public class MockAccountManager implements AccountManager
{
private Hashtable accounts = new Hashtable();
public void addAccount(String userId, Account account)
{
this.accounts.put(userId, account);
//见注释1
}
public Account findAccountForUser(String userId)
{
return (Account) this.accounts.get(userId);
//见注释2
}
public void updateAccount(Account account)
{
// do nothing
//见注释3
}
注释1：addAccount方法用了一个实例变量来作返回值。因为你有许多account对象需要返回，我们用一个hashtable来装载他们。这样可以使mock具有一般性而且支持不同的测试案例：某些测试只建立一个account对象，某些测试可能建立多个account对象。
注释2：addAccount告诉findAccountForUser方法返回什么参数。
注释3：updateAccount更新了一个account但是没有任何的返回值。因此你什么都可以不做。但他被transfer调用的时候，只要被正确更新，他将什么都不用作。
JUnit best practices:不要再mockobject中写入商业逻辑（don’t write business logic in mock objects）
在写一个mockobject的时候最需要考虑的一点就是不要再其中加入任何的商业逻辑。他必须是一个哑对象（dumb object）只作测试代码让他做的事。环一句话说。他完全靠测试来驱动。这个性质和stubs--包含所有的逻辑--完全相反。
由两个重要的推论：1，MO很容易产生。2,因为MO只是一个空壳，所以他很难破坏而且不用对他们进行测试。
现在我们可以对AccountService.transfer进行测试了。
下面是一个典型的应用mock的测试案例。
JUnit best practices:只测试那些可能崩溃的部分(only test what can possibly break)
你可能注意到你并没有模拟account类。原因是因为数据访问对象是不需要被模拟的。他们与环境无关而且十分简单。其他的测试用到了account对象，因此间接的对他进行了测试。如果在这上面操作出现错误，以来他的测试就会报错。在本小节，你已经有了对MO的明确的了解。在下一部分里面，我们将告诉你用mock来写单元测试来重构你的代码