寫測試是一個很奇怪的過程，大腦的思維方式和直接寫應用代碼好像有些不同，呵呵，沒搞清楚，我想這是咱和大師的區別吧，還只是只可意會不可言傳，我一直的觀點是，真正懂的人是能將模糊的東西解釋成清晰的概念的。無論如何在我準備開始動手寫這痛苦的測試代碼時，我又有新想法了，為什么不在開始就不獲取冗余數據呢，雖然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的測試模式顯得那么簡單，最后，終于一路綠燈了。呼………..