在JMockit的工具箱里面，伪造API（Faking API）为假实现提供支持。典型场景就是对部分方法和构造函数进行假实现（伪实现），同时保持其他方法和构造函数原有实现。此外，外部库的类经常需要被伪造。
伪实现对于依赖外部组件、资源的测试很有用。比如邮件、web服务、复杂的类库等等。通常，我们需要复用伪实现，把其作为测试的基础之一。此外，一个测试类中同时使用Fakding API和Mocking API需要注意，这通常被视为一种错误的方式。
使用伪实例替换实际实现对于使用依赖关系的代码是完全透明的，并且可以在不同的范围内打开和关闭替换：单个测试，单个测试类中的所有测试或整个测试运行范围内。
1 伪方法和伪类
在Faking API场景中，继承自mockit.MockUp的类，即为伪类，T是要被伪造的类。伪类中被注解为@Mock的方法就是伪方法。下面的示例展示了针对javax.security.auth.login.LoginContext的一个伪类，及里面的多个伪方法。
publicfinalclassFakeLoginContext extendsMockUp<LoginContext>
{
@Mock
publicvoid$init(String name, CallbackHandler callback) {
assertEquals("test", name);
assertNotNull(callback);
}
@Mock
publicvoidlogin() {}
@Mock
publicSubject getSubject() { returnnull; }
}
当伪类被应用于真实类的时候，真实类中有对应的伪方法实现的那些真实方法的实现会被替换掉。换句话说，真实类在测试时被伪造了，提供了伪方法的方法被调用的时候会按伪方法的实现做出响应。提供了伪实现的方法被打断了，直接导向相对应的伪方法。伪方法被执行，并返回结果给方法的调用者（当然如果发生了异常或错误，就没有返回了）。通常，调用者就是被测试类，伪类是调用者的一个依赖关系。
每个@Mock方法必须与对应的真实方法有相同的签名。方法签名包括：方法名、参数。对构造函数，在这里签名只包括参数，用”$init”作为固定的名称。如果对应的真实方法在对应的类或类的超类中没找到，在应用伪类的时候会抛出IllegalArgumentException异常。注意：可能会因为真实类的重构而引发了这个异常（比如重命名了真实方法）。
最后，没有必要伪造所有方法。没有在伪类里面定义对应伪方法的方法，会保持不变。也就是这些方法不会被伪造，继续保持原有逻辑。
