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

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

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

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

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

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

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

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

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