案例三

　　虽然目前已经有很多的mock工具，如jmock，easymock等工具，这些工具可以很方便的构造mock类，但是这些类的可读性会比较差，因此提倡自己写mock类，这样不但可以增加可读性，并且对于mock类的实现我们可以比较自由。

　　案例四

　　对于较大类的解决，在实际工作中我们可能会遇到一个非常庞大的类，这个类可能有几百个方法，那么如何提高这种类的可测性，提倡一个原则（单一职责原则SRP），每个类应该仅承担一个职责：它在系统中的意图应当是单一的，且修改它的原因应该只有一个。

　　案例五

　　如果需要在遗留代码中添加一些新的功能，一些非常简单的功能的时候我们应该怎么做，如下代码，我们需要在parse方法之后加上日志记录，那么我们可以通过以下几种方法来做：


public class Parser{
public void parse(){
  .........
}
}


　　我们可以添加一个方法叫做parseWithLogger()

　　如：


public class Parser{
 public void parseWithLogger(){
    Logger loger = Logger.log(.....);
    parse();
}
 public void parse(){
 ......
}
}


　　这样我们不需更改原来的parse方法进行修改，我们之需要增加一个新的方法，然后在我们测试用具中对这个新的方法进行测试行。

　　我们也可以这样更改代码，把原方法改名为parseWithoutLogger()


public class Parser{
public void parseWithoutLogger(){
   ...........
}
public void parse(){
  Logger log = Logger.log();
  parseWithoutLogger();
}
}


　　这样对代码的改动也不是很大，我们可以在测试用具中测试parse方法是否加logger。

　　两种方法对遗留代码都不会造成大改变，我们强调对遗留代码的修改一定要小心，因为遗留代码是没有测试代码，我们不能大刀阔斧的进行修改，只能小步前进，然后对遗留代码加上测试用列，保证重构的正确性。

　　当然对遗留代码的可测性提高还有很多方法，可以参考Michale Feathers 写的<working effectively with legacy code>。