关于土豆、番茄和easymock的争论

        今晚小组讨论，又说到了 easymock的测试问题，和前几次不同，这次easymock不再是鸡肋的角色，而倒是像一个碍手碍脚的包袱。全因为我们发现它需要手动配置许多“原材料”和“最后的大餐”。
       现在说说它的使用原理：比如说你要测试Object A，而Object A中有内部成员Object B，并且Object B实现了接口Interface C，而在Object A中只调用了Object B中实现了的Interface C的方法（这时应为现在的easymock只能够模拟接口类，对实体类无能为力）。那么就可以给Object A注入一个由easymock.createMock(Interface C.class);生成的mock对象来模拟ObjectB的行为。easymock会记录并核对objectB的方法调用种类、数量、*顺序，如果有错误或者和录制过程中的不同，就会报错。
       下面来说一说复杂一些的情况下easymock的使用方法，今天的争论也主要集中在这里。首先要明确几点：

1. easymock不会实际调用它所mock的对象（即ObjectB）的方法实现，而是只通过线程捕捉、记录调用过程。
2. 因为上面的原因，要对ObjectB有返回值的方法手动设定返回值，供被测试的objectA作为“原材料”使用，打个比方就是土豆和番茄。
3. 时刻都要记住，你是在测试ObjectA，而不是ObjectB。因为一开始不太熟悉easymock的使用，经常会将注意力集中在那个mock对象上，但是反倒忽略了真正的被测试对象——Object A。
4. easymock永远不会替你验证被测试方法的返回值正确与否！！这个需要你自己来构造一个，基于ObjectB的指定的返回值数据的、正确的预期返回值，来通过assertEquals（）或者更复杂的方法来判断返回的结果是否正确。

明确了这几点，就知道我们需要做几件事：

1. 准备各种原材料：mock对象的返回值、被测试方法的预期返回值
2. 录制mock行为：预期你的mock对象会被调用到哪些方法，次数和顺序，按照你的需要选择不同层次的mock。通过expect() .andReturn() .times() 等方法对预期进行设置。还可以用EqXXX()等方法对入口参数进行相等或是更复杂的match匹配设定。
3. replay，实际调用ObjectA的方法，取得返回值。
4. verify，用easymock验证是否所有的方法调用都是按照计划进行的。
5. assertEquals()判断ObjectA的返回值是否和自己手动建立的预期返回值相等，从而最终判断测试是否成功。

由于easymock是白盒测试，所以我们可以预期ObjectB的方法调用。
由于easymock不提供也不可能提供最终的返回值正确性验证，所以我们需要自己来进行验证，并且要预知返回值的正确结果。
注：*easymock提供三种mock对象：普通的mock、NickMock、StrictMock。三者对方法的检查不尽相同，只有strictMock会检查方法调用的顺序。