記得我以前寫過一個文章是有關于4層web結構單元測試的，今天打算對TDD的環境問題重新討論一下。

我當時的4層結構的單元測試時間上是從DAO到Service到Action再到JSP一種漸進測試，但是的想法是，先測DAO，那么Service對DAO的調用就有保證了，測試了Service，那么action調用service就有保證了。。。這樣一層一層下來，我每層測試的目標也就達到了。這里其實我用了一個技巧，就是通過測試的順序，來逐漸的構建了每層測試所需的外部環境。當然從這個角度來看，我當時使用的方法更貼近于集成測試了。

一般做TDD的時候最大的問題就是如何處理外部環境，這一般包括本身業務邏輯環境和技術框架環境。

在當前這個新項目中，我首先嘗試對一個具體渲染器的測試方式就是用mock，這里用的是比較好用的easyMock。開始的時候覺得mock的方法很好用，但是當我發現我的待測方法中有多個需要mock的對象時（a.getX();b.getY();c.getZ()）或者一個mock對象要通過多次級聯獲取時（如 a.getB().getC().getD().getE()）就會發現mock的代價讓你高到很不原意mock的地步。

而且當我們的框架卻制造了一個讓我無法逾越的障礙，就是我們對于manager（DAO）的調用都是用一個類的靜態方法封裝管理（比較奇怪為什么不用spring來進行管理呢）。這樣靜態方法就沒法mock了，于是乎，要想測試就要采用build的方法了，就是你可以在你的testCase中事先通過已經實現好的DAO方法把需要使用到的業務對象真實的build出來，這樣你就可以知道你的被測方法中通過dao調用到的數據究竟是什么了，于是就可以對你期望獲得的結果和經過實際方法得到的結果進行對比驗證了。
看起來好像也是比較方便，但是實際上當你待測對象的業務模型，依賴于3-4級以上的相關模型時，你就會感覺到，這樣build是一個代價非常高的事情。這種代價通常會讓開發者喪失對TDD的興趣了。

我發現其實在測試的時候我更加關注的是業務數據的build，而系統架構通常是服務于業務的。所以我就開始考慮，能否有個方法構建出最基本需要的業務模型數據呢。查閱了一些網上工具，發現沒有能夠滿足我當前需求（kodo做持久層，還有我們自己研發的知識引擎），于是就自己簡單做了一個InitialTestObject，想法很簡單就是通過一個xml文件然后根據已知的業務模型結構定義好數據，然后根據固定的規則初始化好業務數據，并且存放到一個map中去（方法比較簡單我就不列出源碼了），然后再使用時把初始化放到setUp中去，這樣在測試的時候就可以根據你的需要直接從map中獲取到一個實際的業務對象用于測試的時候使用了，最后記得要在測試完成后要在tearDown中清除初始化的數據。這樣處理后我發現在測試時就感覺到很方便了，用到什么直接從map中取就可以了。

也許有人會說這樣做不還是是集成測試了嗎，你build的時候需要數據庫、持久層啊什么的，這里我不想來爭論究竟是屬于單元測試還是集成測試，因為它屬于什么對于我們的功能來說是沒有意義。無論什么測試的最終目標就是讓我們的功能可用。

至于構建環境的實現我只是給出了一個對于我當前項目代價最小的方法，其實如果你的項目不是使用靜態方法的話，可以考慮構建一個完全mock的環境這樣就可以稱之為單元測試了。
而且對于這個InitialTestObject我覺得可以做成一個開源的小工具，支持各種不同的持久層（jdo，hibernate），然后根據我們定義的持久層模型做為我們的業務規則，就不需要自己編寫具體的初始化規則代碼了，你只需要寫xml數據并指定好對應的持久層模型，希望大家可以對這個想法對提提建議，也許已經有人做了，那我就不做重復功了。

下篇預告：think in refactor         時間：待定