写测试是一个很奇怪的过程，大脑的思维方式和直接写应用代码好像有些不同，呵呵，没搞清楚，我想这是咱和大师的区别吧，还只是只可意会不可言传，我一直的观点是，真正懂的人是能将模糊的东西解释成清晰的概念的。无论如何在我准备开始动手写这痛苦的测试代码时，我又有新想法了，为什么不在开始就不获取冗余数据呢，虽然Decorator模式在这里的应用很具有吸引力，因为它本身毕竟够简单明了，不过，同时想到Document对象本身的一些特点，首先它是大对象（呵呵，感觉上DOM的对象都好大哦，但其实还没有真正理解它到底是怎么个大法），其次，如果是过滤数据，那么势必要遍历该Document的节点，这样的话似乎处理起来的效率不怎么样，这怎么都不如在一开始就不从ResultSet中获取冗余数据来得简单明了。于是想到，在自动生成column节点上现在还是很弱的，可以用Builder模式来重构它，这样的话，可以通过替换column节点的builder来实现过滤，而且目前来说，也确实是只有自动生成column节点的情况才需要过滤冗余数据，所以也不需要考虑由XML配置模板定义好columns节点的状况；而原来默认的生成方式可以立刻就被提炼出来作为默认builder；这样添加的代码实际也很少，我想几乎更少些吧，因为原来在处理冗余数据时需要遍历Document，而现在只要认准了从ResultSetMetaData获取的字段名，对需要过滤的字段不生成column节点就Ok，而有新的变化出现时，只要替换重新实现builder接口就可以了。当然了，原来这个ResultSet解析器是有测试类的，也有相关的测试，那么将原来生成column部分代码提炼出来作为默认的builder后，可以跑以前的测试，啊哈哈哈哈，这几乎不费吹灰之力，ECLIPSE的重构功能很容易将生成column的代码提炼成一个方法，然后把这个方法提升成一个接口，接着如此如此（不用说了）就弄好了一个默认builder实现，然后解析器加个builder类属性，同时生成它的set方法，一切ko后跑测试（这里都是工具自动做的多，我这一步跨的是会大些的，不过多跑测试总是没什么坏处的，反正跑一次也就几秒中，也许还不用呢，^_^），一路绿灯。重构完成，sweat（注意到了吧，到目前为之，其实我没有写测试，而是使用了原来的测试代码，而代码部分也多是自动生成的。最重要的是，这里使用builder模式，其接口也被测试过了，所以后面加的builder实现就可以不考虑这点了，而只是完全的功能需求测试，功能需求总是可以很单一的，自然就简化了测试代码）。
现在又回到开始了，我的目标又换了，呵呵，新目标：一个builder接口实现，过滤冗余的字段。如何测试呢？一个ResultSet做输入参数是必要的，输出的话要没有冗余数据，实际应用中要过滤的字段名是固定的（呵呵，别忘了我的最初的目的，是过滤由于SQL查询使用公共接口导致有相同的冗余字段出现。），我可以SELECT出来一个空结果集，其字段都是我要过滤的那些字段名（这里，如前所述，数据体不是我要关心的内容，因为数据体的是根据column节点生成的，所以我只要检查column节点对不对就可以了，这样也简化了我的测试代码），当然，在这些之前是重置ResultSet解析器的builder对象为将要实现的目标代码类，很快就完成了所有的代码，跑测试，出错，修改，跑测试，Kent Back的测试模式显得那么简单，最后，终于一路绿灯了。呼………..