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

• 职责不明确

　　类或类方法的职责不明确，违反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

　　使用成熟单元测试框架

　　除了最基本的Junit外，Opensource提供了很多非常有价值的单元测试框架，熟练使用这些工具，可以提高测试的效率。包括对准备大量的数据，以及j2ee的框架代码。

　　现有代码的可选自动化测试工具：

　　1. POJO：JUnit, JMock或者EasyMock

　　2. Data Object：DDTUnit。准备大量数据。

　　3. Dao：DBUnit。初始化数据库。批量产生数据库数据。

　　4. EJB： MockEJB或者MockRunner

　　5. Servlet：Cactus

　　6. Struts：StrutsUnitTest

　　7. XML:XMLUnit

　　8. J2EE: MockRunner

　　9. GUI: JFCUnit, Marathor

　　10. Other: JTestCase（采用XML定义测试过程）