编辑: 飞翔的荷兰人 | 2015-06-24 |
6 简介 传统的使用模拟对象为了到达独立的解决方案需要强加明确的在测试代码级别的约束. JMockit被创建作为规避这种约束的替代,通过使用 java.lang.instrument Java 6+ 的包进行字 节码技术 (还使用了 - 较少的程度上 - 反射 , 动态代理, 和自定义类的载入). 针对伪装对象的主要约束是需要模拟的可选类不是要实现一个独立的接口,就是所有的需要 被模拟的方法必须为可以被重载.此外,依赖的实例化必须依赖于外部的依赖单元,这样才 能有一个代理对象(模拟对象)被传入代替实际上每个依赖的实现.此外代理类不能被简单 的初始化使用new操作符在客户端代码中,因为构造方法的调用不能通过传统的技术进行拦 截. 总结来看,有些一个传统的模拟方法在设计使用中的一些限制: 1. 应用类必须实现一个独立接口 (为了使用 java.lang.reflect.Proxy) 或者是不被什么 final (为了能够动态生成一个包含重写方法的子类的).在第二个情况下,需要被模拟的实例方 法不能为最终的. 显然,建立java接口只用来模拟的实现是不需要的.分离的接口(或 者是更普通的抽象)只有当在生成代码中有多个实现的时候才被建立. 在 Java, 标记类 和方法为final是可选的,即使大多数的类不是被设计为扩展子类用的.申明他们为最终类 是社区或者是通常的java编码实践中所推荐的(像书中 Effective Java, 2nd edition , 和 Practical API Design ). 此外,它允许静态的分析工具 (例如Checkstyle, PMD, FindBugs, 或者 你的 Java IDE) 提供了有用的对代码的警告 (例如,关于一个最终方法申 明了将抛出一个特殊的需要检查的异常,但是实际上并没有抛出;
这种警告不会出现在一 个给定为非最终的方法中,由于它的子类可能重写它,可能抛出异常). 2. 非静态方法的模拟行为有时需要被调用. 在实际中,许多的 APIs 包括静态方法最为入 口或者是一个工厂方法.为了能够偶尔模拟他们是一个很实际难以避免的开销,比如建 立包装类而这些类是不存在的. 3. 需要被测试的类需要提供一些方........