注:
1）这里有一个TestAdd是使用MyEclipse的JUnit的框架写的普通单元测试,TestMul是通过EasyMock写的单元测试；
2）引用jar包如下：
3) 运行单元测试
总结:
1.关于EasyMock的详细使用，点击：http://easymock.org/
2.如果发生 java.lang.NoClassDefFoundError异常
java.lang.NoClassDefFoundError: org/objenesis/ObjenesisHelper
at org.easymock.internal.ObjenesisClassInstantiator.newInstance
...
需要引用objenesis-1.1.jar包，下载地址：http://download.csdn.net/download/dreamStronger/3074415
3.如果发生java.lang.AssertionError异常
java.lang.AssertionError:
Expectation failure on verify:
Algorithm.Add(3, 4): expected: 1, actual: 0
...
则注意在方法调用后面调用anyTimes();函数如果需要expect的方法没有返回值, 应该这样写: 先执行mock的要调用的方法, 然后调用EasyMock.expectLastCall().anyTimes();
4.Recored - Replay - Verify 模型
record-replay-verify 模型容许记录mock对象上的操作然后重演并验证这些操作。这是目前mock框架领域最常见的模型，几乎所有的mock框架都是用这个模型，有些是现实使用如easymock，有些是隐式使用如jmockit。
Record
我们开始创建mock对象，并期望这个mock对象的方法被调用，同时给出我们希望这个方法返回的结果。这就是所谓的"记录mock对象上的操作", 同时我们也会看到"expect"这个关键字。 总结说，在record阶段，我们需要给出的是我们对mock对象的一系列期望：若干个mock对象被调用，依从我们给定的参数，顺序，次数等，并返回预设好的结果(返回值或者异常).
Replay
在replay阶段，我们关注的主要测试对象将被创建，之前在record阶段创建的相关依赖被关联到主要测试对象，然后执行被测试的方法，以模拟真实运行环境下主要测试对象的行为。
在测试方法执行过程中，主要测试对象的内部代码被执行，同时和相关的依赖进行交互：以一定的参数调用依赖的方法，获取并处理返回。我们期待这个过程如我们在record阶段设想的交互场景一致，即我们期望在replay阶段所有在record阶段记录的行为都将被完整而准确的重新演绎一遍，从而到达验证主要测试对象行为的目的。
Verify
在verify阶段，我们将验证测试的结果和交互行为。
通常验证分为两部分，如上所示： 一部分是验证结果，即主要测试对象的测试方法返回的结果(对于异常测试场景则是抛出的异常)是否如预期，通常这个验证过程需要我们自行编码实现。另一部分是验证交互行为，典型如依赖是否被调用，调用的参数，顺序和次数，这部分的验证过程通常是由mock框架来自动完成，我们只需要简单调用即可。
在easymock的实现中，verify的部分交互行为验证工作，会提前在replay阶段进行：比如未记录的调用，调用的参数等。如果验证失败，则直接结束replay以致整个测试案例。
record-replay-verify 模型非常好的满足了大多数测试场景的需要：先指定测试的期望，然后执行测试，再验证期望是否被满足。这个模型简单直接，易于实现，也容易被开发人员理解和接受，因此被各个mock框架广泛使用。
