测试案例testDefaultBehavior()将为我们打印出mock对象默认的行为，输出如下：

　　可见easymock内部已经做好了toString()和hashCode()实现。

　　在测试案例testCustomizedBehavior()中，我们试图通过EasyMock.expect()来指定toString()和hashCode()的行为，但是运行时遭遇错误：

　　从"no last call on a mock available"的描述上看，easymock根本没有把对toString()方法的调用记录(record)下来作为一个对mock对象的调用。

　　因此，在使用mock对象时，请注意equals(), hashCode()和toString()三个方法无法更改其行为。

　　(2) class mock的限制

　　相对于interface mock，class mock下easymock限制更多，除了上面谈到的equals(), hashCode()和toString()三个方法外，还有以下限制：

　　1. final 方法不能被mock

　　2. private 方法不能对mock

　　(3) 静态方法

　　对于静态方法，easymock也无法mock其行为。

　　由于这个限制，当被测试类中有静态方法调用时，典型如单例方法调用，lookup方式的依赖查找，easymock就会力不从心。从这个角度上，推荐尽量使用IOC 控制反转/ DI依赖注入的方式来实现依赖的获取，而不要使用lookup的主动查找方式。

　　实际开发中，当发现有因为静态方法的限制从而导致easymock无法mock我们期望的行为，造成测试案例"不好写"，“写不下去”时，请换个角度思考：为什么要用静态方法?可不可以改成注入?

　　(4) 解决的方法

　　如果由于某些原因必须使用静态方法或者定制final, private方法的行为，则可以考虑搭配其他mock框架来完成功能。

　　以静态方法方法为例，一个典型的使用范例是：使用jmockit来定制静态方法的行为，指定其返回easymock创建的mock对象，然后使用easymock的标准方式定制这个mock对象的行为。