Morning@Weblog

前段时间在做部门平台的再工程，其中有一项工作是去除原先核心模块的EJB代码。这实际上是一个典型的重构过程，因为它非常符合重构的定义——在保证外部功能不变的情况下，对现有代码的调整。于是，我在每次修改代码之前，都会先将原有代码所反应出来的外部逻辑用测试用例表达出来，从而保障修改过程是在严格的契约控制之下进行的。这可以说是在我开始实践TDD&Refactoring至今，所遇到的最为典型的一个案例了。

不过期间也发现一些问题，比如：既有代码本身的易测性对TDD的施行是至关重要的。一个难于测试的软件系统，会导致编写测试用例异常困难（比如代码中大量的使用Factory或Single模式）。开始阶段，我花费了大量时间在编写测试用例上（实际上，在代码修改上花费的时间所占比重并不大）。其中的一个测试用例，直到最后完工时，才跑通，整个周期非常之长。于是这就很容易导致一种倾向：即使有心实践TDD/Refactoring者，在经历了一段费劲周折而进展甚微的过程之后，就干脆放弃了测试，冒险直接修改代码。

结合TDD，重构遗留系统的过程中遇到的另一个常见问题是，系统的耦合导致测试用例很难写。这一点在我的这次实践中也有所体现。也许针对某一个类的测试会牵涉多方“利益”，此时，最为有效的办法就是借助于mock test。假如只关心系统某个部分的测试，那么就务必要利用mock object来将之隔离。当然mock object的编写也是需要计入成本的。同时，这也教会我们，在编写实现代码时，务必要考虑可测试性，诸如针对接口编程这样的实践是一定要贯彻执行。