重构这个大类的基本思路还是来源于业务逻辑的划分,可以看到work中主要完成3件事:下载文件、合并文件和处理单词,这里可以采用模板模式:

  具体的实现在HandleTempleImpl里面:

  这样对于真正的处理能够比较充分地测试,比如mergeFile()现在完全不依赖与downLoadFile()的调用而可以直接测试了。

  四、原则与总结

  以上实例只是一些普遍性较强的例子,实际上细节点非常多,从上也可明显看出如果代码结构不合理可测性确实是非常低的。

  这里有一些代码书写或者重构的原则,对于提高可测性有较大的帮助,较全的重构方法可以参考《重构》这本经典书籍:

  1)形成模板方法(如3.3模板模式的应用)

  2)引入断言(比如每个方法中判断传入参数的合法性,这样在测试时可以减少异常参数测试的工作量)

  3)用多态替代条件语句(如3.2策略模式的应用)

  4)用异常代替错误码(测试时只需要调用后判断预期异常)

  5)将查询方法与修改方法分离(测试时由于查询和修改职责单一后会降低构造数据的成本)

  6)以明确函数取代参数(测试时由于函数明确、职责单一也会降低构造数据成本)

  另外,在测试时也有一些tips:

  1)用TestNG或者Junit的参数化来减少代码量,并尽量将测试数据单独一个类出来;

  2)用ObjectFactory的方式来获取默认数据,这样对于构造拥有多个属性的类的实例时将大大减少工作量,因为只需要在默认对象的基础上做些修改;

  3)使用Mokito的注解方式来mock对象。