接下來抽象出SearchEngine的接口ISearchEngine，并讓SearchEngine實現(xiàn)該接口。其中接口方法包括ExactSearch和BlurSearch方法。將前面的測試代碼作小小的修改，修改后同樣需要在NUnit中運行，保證順利通過：
　　[Test]
　　　　public void TestSearching()
　　　　　　{
　　　　　　　　  ISearchEngine engine = new SearchEngine();
　　　　　　　　  Assert.IsNotNull(engine);
 
　　　　　　　　  ……
　　　　　　　}

　　考察SearchResult類型，該類型的對象應該在整個程序中只保留一個對象，因此，應對此采用單例模式。修改測試代碼：
　　[Test]
　　　　public void TestSearching()
　　　　　　{
　　　　　　　　 ISearchEngine engine = SearchEngine.Instante;
　　　　　　　　  Assert.IsNotNull(engine);
 
　　　　　　　　  ……
　　　　　　　}
　　根據(jù)測試代碼修改程序代碼，將SearchResult類型的構造函數(shù)改為private，并提供只讀的靜態(tài)屬性Instante，以此來獲得單例對象。

　　僅僅是這樣還不夠的�？紤]到搜索的范圍有多種情況，如internet，local machine，DB等。SearchEngine類型應該具體化不同類型，并同時實現(xiàn)ISearchEngine接口。例如搜索范圍在internet，測試代碼如下：
　　[Test]
　　　　public void TestInternetSearching()
　　　　　　{
　　　　　　　　  ISearchEngine engine = InternetSearchEngine.Instante;
　　　　　　　　  Assert.IsNotNull(engine);
 
　　　　　　　　  ……
　　　　　　}

　　既然有如此多的類型，類型的創(chuàng)建就必須通過工廠進行管理。此時測試代碼需要做進一步的修改：
　　[Test]
　　　　public void TestInternetSearching()
　　　　　　{
　　　　　　　　  ISearchEngineFacotry fatory = new 　　　　　　　　InternetSearchEngineFactory();
　　　　　　　　  ISearchEngine engine = factory.CreateInstante(“Internet”);
　　　　　　　　  Assert.IsNotNull(engine);
 
　　　　　　　　  ……
　　　　　　　}

　　同理，我們應該分別實現(xiàn)測試方法TestLocalSearching()和TestDBSearching()。

　　按照這樣的思路，分別對存儲功能和顯示功能進行重構。記住，每做一步重構，都需要嚴格按照TDD的方式。首先寫出測試代碼，然后在NUnit運行。如果是紅燈，需要寫出相應的代碼，再運行NUnit，直到全部均為綠燈為止。

三、第一步的小結

　　表面上看，這樣繁復地寫測試代碼，程序代碼，確實是有些Kill Time了。但我們需要認真地思考所謂“發(fā)現(xiàn)價值”的意義。通過測試先行的方式，以模擬客戶應用的狀態(tài)來考量客戶的需求，并通過此驅動程序員一步一步地到達“生產價值”的終點�！鞍l(fā)現(xiàn)”與“生產”并行不悖，同時“質檢員”一直跟隨其間，保證了產品的質量。

　　就好比Nike鞋的生產，必須以體貼用戶的角度出發(fā)，設計出吸引人的樣式，那么大規(guī)模的生產才會有盈利的可能。

　　TDD的生產過程也許慢了一點，但請不要忽略了它其實已經省去了編碼后單元測試的時間。相加相減之后，又會浪費多少時間呢？所以，千萬不要以“時間緊”的理由來搪塞我哦。

　　四、考察第三步——收獲價值

　　傳統(tǒng)的方式，在產品生產出來之后，緊接著的是大量的測試，其中也包括單元測試；最后收獲了產品、一大堆源代碼和文檔。而TDD的方式，既省去了單元測試的過程，同時還收獲了另外一樣上帝賜予的禮物——測試類或測試套件。

　　測試類絕對是一件奇妙的禮物。必須認識到它的價值不只是在于“發(fā)現(xiàn)價值”的階段，它同樣是我們的“收獲”。

　　第一：比代碼更好的文檔、比文檔更好的代碼
　　有了它，不用鉆進浩如煙海的文檔里，四顧茫然了。文檔的文字描述既不準確，容易產生歧義，又容易產生文檔同步的問題。也許它能促進你對業(yè)務和架構的理解，但對于程序本身，你無法從文檔中得到基本的啟示。

　　那么看程序的源代碼嗎？你會在眾多的類對象和方法中繞來繞去，最后一頭霧水，精疲力盡之后，還是一無所獲。

　　而看測試代碼就不同了，你不需要了解每個方法的具體實現(xiàn)，因為測試代碼是從客戶的應用角度來書寫的，看完測試代碼，你會很輕松地理清程序結構的脈絡。

　　第二：新兵訓練營的絕佳教材
　　也許你的項目組新進了員工，如果他熟悉TDD，那么，這些測試類是他熟悉項目的最好文檔；如果他還沒聽說過TDD，不用著急，先把這些測試類給他。只要他不是程序設計的新手，我想這個新兵會很快熟悉項目組開發(fā)的方式。再讓他寫幾個測試樣例，他會立即投入到TDD的懷抱中來的。

　　第三：滿載而歸的信心
　　項目開發(fā)中，成員最寶貴的除了認真、努力、團隊精神之外，就是信心了。這里所謂的信心，并非是對自己能力充滿樂觀的估計和客觀地評價后，表現(xiàn)出來的精神面貌，而指的是程序員對代碼正確性的信心。無論這些代碼是自己寫的，還是他人寫的，只要嚴格按照TDD的要求進行，你都會對它們充滿信心。雖然不能保證沒有bug，但必須承認的是通過單元測試，我們已經將bug降低到最小了。

五、結論

　　中國企業(yè)在企業(yè)運行價值鏈上，走好了利潤最低的第二步，卻忽略了“發(fā)現(xiàn)價值”和“收獲價值”對于一個企業(yè)的重要性。韓國三星在幾年之前還是一個虧損600多億美元的企業(yè)，如今它已經成功地扭虧為盈，并躋身世界五百強。原因很多，但不可忽視的是，他在價值鏈的首尾兩步中作得很好。從高端產品中發(fā)現(xiàn)價值，找到了目標市場；從品牌創(chuàng)造中收獲了價值，走向了世界。

　　我不是說軟件開發(fā)一定要采用TDD的方式，它自然也有很多缺陷。然而，我們在開發(fā)的過程中，同樣要重視設計的“發(fā)現(xiàn)價值”階段，然后在收獲產品的同時，不要忽略了還應該收獲其他同樣值得珍視的“價值”。從這一點來看，也許TDD更符合這種價值鏈的模式。而我們程序員千萬不要舍本逐末，過于偏執(zhí)地重視“生產價值”，以致于在軟件開發(fā)方法上，總是落后于人，進而受制于人!

　　最后，謹以我之愚見，思考TDD的方式，認為TDD內力精深，大約分為四種無上之力：
　　1、驅動力——驅動程序代碼編寫；
　　2、學習力——新兵訓練營之絕佳教材；
　　3、自信力與他信力——bug降到最低；
　　4、控制力——與重構緊密接合，牢牢控制開發(fā)過程。

更多軟考資料請訪問：考試吧軟件水平考試欄目

希望與更多網(wǎng)友交流，請進入考試吧軟件水平考試論壇