单元测试实践小结2

讨论完测试的关注点后，需要看看实际面临的具体困难

职责不明确
    类或类方法的职责不明确，违反SRP原则．一个类或方法处理了本不该有它处理的逻辑，使得单元测试需要关心过多的外部关联类

静态方法
    静态方法使得调用者直接面对实际的服务类，难以通过其他方式替换其实现，也难以扩展

直接访问对象实例
    调用者直接实例化服务对象，从而使用服务对象提供的服务．同静态方法一样，直接面对其服务类

J2se和J2ee标准库或者其他类库
    标准类库中有非常多的接口调用使得调用者难以测试 e.g JNDI, JavaMail, JAXP

准备数据及其困难
    编写测试用例需要外部准备大量的数据

针对这些困难，可用解决方法如下：

重构系统
    对于职责不明确的代码，只有通过重构才可以达到单元测试的目的。

Self-Delegate test pattern
　 针对于class的测试，使用自代理测试模式, 使得测试时，可以重写被测试类的一些方法．达到测试的目的．通过extend class override methods来实现。Inner class mock方法也一样。不过这种方法比较别扭

编写Stubs和Mock object
1. 接口的mock比较容易，测试时，编写stubs和mock object来辅助测试，是非常重要的技术． Mock object分动态mock和静态mock．采用EasyMock可以很好的实现动态mock。
2. 具体类的mock，也很简单，通常利用子类继承的方式实现，利用cglib框架可以很好大达到测试目的。
3. 静态方法的mock。静态方法由于是直接面对服务对象，比较麻烦。不过，并非不可以测试，实际我们可以利用classpath的特点来实现。

    方法很简单，mock类与建立一个将被mock的类的package，class name以及方法签名完全一样，但方法实现却是mock过的。在运行测试用例时，把mock类打成jar（不一定要这么做）， 在配置classpath时确保，该jar的位置在当前class之前，就可以实现替换。代码如下：StaticMock.rar

1