在這一篇中，我們將采用Step By Step的方式，重點介紹如何在實際開發(fā)過程中，使用測試先行、代碼復查和重構。形成這樣的開發(fā)習慣之后，編寫代碼將不再是實現、排錯的過程，而變成制造快樂的過程：寫一個測試、實現、測試通過，再寫測試、再實現、再通過測試。完成一件任務，能引發(fā)多處階段性的快樂，這對于我們的工作心態(tài)大有好處。

    我們的工作目標，是為Db類增加三個構造方法。

 

    先解釋一下為什么要先寫測試，再寫代碼，實際上，有下面的七個方面的好處：

     1、關注點集中

   2、單一的成功被無數成功取代，心態(tài)將更為良好：腦力工作，情緒是非常重要的，大家如果正常的統計自己的有效工作時間，往往會發(fā)現自己一天的有效工作狀態(tài)持續(xù)時間非常短。一個很經典的說法，是多數程序員每天正常工作的時間平均下來不超過一個小時。

    3、占在類的用戶角度，來看待類的設計，有助于

    4、建立起整個項目的質量基礎

    5、累積下來的單元測試，是后期代碼修改的準則

    6、Bug的修復將更為精準。

    7、單元測試，就是團隊中其他程序員的使用手冊。

   一魚七吃，這樣的事情，為什么不做？

 

    代碼復查，簡單的說就是逐行閱讀代碼，從而找出潛在的問題和代碼結構上的壞味道。據說，代碼復查能夠發(fā)現項目中一半以上的Bug，當然，在代碼尚未發(fā)布、或者Bug尚未轉移到團隊其他成員處的時候，修復Bug的成本是最低的。

    代碼復查是很枯燥的工作，自己復查、團隊成員交互復查都行。敏捷方法中比較極端的例子是雙人編程，這樣，實際上代碼復查貫穿于整個開發(fā)時間。

 

    重構，消除代碼中壞的味道，這里最常見的一種現象是“重復的代碼”。

    由于有大量的單元測試，重構過程中保持全部單元測試通過，有助于實現我們的目標：僅僅調整代碼的結構，而不會令功能實現上出現問題。

    代碼質量，并不是代碼工作如何精準，而是代碼的結構是否做到了最簡化。請注意，稍稍不留意，代碼增加的少許復雜性，會令同事閱讀困難、甚至令自己閱讀困難，各處的復雜性累積之后，會造成Bug數量的大幅增長，維護也變得困難。這里可以參考用戶體驗的一句名言“多一次擊鍵，用戶可能永遠不會使用這項功能”。

 

    嘮叨完畢，我們先做好準備。

    我們創(chuàng)建一個單元測試項目，引用我們的工作項目Faster.Data類庫項目。在單元測試項目中增加一個配置文件App.config，我們將數據庫連接信息保存在這個配置文件中。

    單元測試中最常見的問題，是“數據庫如何測試？”

   我曾經饒有興趣的使用Mock，但最終對自己定下了規(guī)矩，即今后絕不使用任何Mock。原因：Mock對象會大幅增加單元測試的簡潔性，構建Mock對象有時候也需要大量的工作，充滿了Mock的單元測試可讀性很差，團隊成員需要全體掌握相關的知識從而導致對開發(fā)人員的門檻提高，這也意味著成本的提高。

    不過，在這個類庫創(chuàng)建完畢后，數據庫讀寫操作就有了很好的基礎，今后所有應用項目則根本無需對數據庫讀寫進行單元測試。

     我的方法是，建立測試數據庫，保證數據庫所有表格處于空白的無記錄狀態(tài)，即針對每一項測試，測試前要準備數據，測試后毀尸滅跡。

 

    那么，現在開始為Db增加構造方法，我們先做最原始的：

    第一步 在類圖中為Db添加一個構造方法 Db(string connectionString,string providerName)

 

    為什么先做這個？因為這是與配置文件無關的，Db(string configName)，這個從配置文件中獲取上述兩個參數，Db()則默認的使用ApplicationServices配置項獲取上述兩個參數。我們顯然要先做最簡單的。換句話說：先解決構造問題，再解決配置文件的問題。

 

    第二步，切換到這個構造方法的代碼，右鍵，選擇創(chuàng)建單元測試。此時，Ide幫我們在下是項目中增加了一個代碼文件，測試類的名稱為DbTest，嗯，類名加上Test。

    那么，這是第一個基本的概念，測試是以類為單位的，每一個待測試的類，對應一個測試類。多數情況下，類的每一個public成員，對應一個測試方法。我們要牢記兩點：1、不針對私有成員寫測試；2、每一個測試方法都要足夠的簡單，突出該方法的目的。

 

     第三步，我們在測試方法中，寫上這樣的代碼

     Db db= new ("連接字符串","提供者名稱");

     Assert.IsNotNull(db);  //我們期望上一行創(chuàng)建的db對象不為空

 

     第四步，運行測試，出現綠色的“成功”提示。好，現在這個測試已經通過。

 

     第五步，現在我們要確定Db已經正常的連接到數據庫。對，如您所說，Db的State狀態(tài)必須為Open

     我們在測試方法下，再增加一行

     Assert.AreEqual(ConnectionState.Open,Db.State);//期望創(chuàng)建的連接已經打開

     運行測試，當然失敗了，因為我們還沒有做真正的連接工作。

 

    第六步，我們?yōu)閯倓倢懙腄b的構造方法中增加如下的代碼：

factory = DbProviderFactories.GetFactory(provider);           
connection = factory.CreateConnection();
connection.ConnectionString =connectionString;
connection.Open();

 

    第七步，運行測試，通過。嗯，現在這項工作完成。

 

    按照同樣的方式，創(chuàng)建其他兩個構造方法。比如：

    第八步：從某個配置項中定義的連接字符串，創(chuàng)建連接

 

var setting = ConfigurationManager.ConnectionStrings[config];

factory = DbProviderFactories.GetFactory(provider);           
connection = factory.CreateConnection();
connection.ConnectionString =connectionString;
connection.Open();

 

    第九步 重構

    我們簡單的審閱代碼，會發(fā)現第六步和第八步的代碼，顯然有多數重復。那么，創(chuàng)建一個私有方法CreateConnection，包含如下代碼：

factory = DbProviderFactories.GetFactory(provider);           
connection = factory.CreateConnection();
connection.ConnectionString =connectionString;

然后，第六步的代碼便是：

CreateConnection(connectionString, provider);

第八步的代碼變?yōu)椋?/p>

var setting = ConfigurationManager.ConnectionStrings[config];
CreateConnection(setting.ConnectionString, setting.ProviderName);

重復，是最常見的“壞味道”，這里是最淺顯的例子。

 

然后，發(fā)現這種從抽象類DbConnection繼承，然后內置一個DbConnection對象，將所有操作轉移到該對象的方法，實現起來頗多不自然之處。包括：

1、我們實現了所有的抽象成員，但GetScheme之類的成員沒有實現。

2、內置的protected只讀屬性DbProviderFactory沒有實現

3、這個對象實際上包括兩個DbConnection的實例，一個是它自身，一個是內置的connection實例，思路上比較紊亂。

 

此時面臨著問題：是采用靜態(tài)類的方法，還是這種創(chuàng)建自定義Connection的方法，于是我們在團隊項目中增加一個問題Impediments

在項目開發(fā)過程中往往面臨著各種問題，有的是設計上的決策，有的是技術難題。每個成員當遇到這類影響進度的問題時，需要提交相應的信息，至遲在第二天早上的15分鐘例會中，項目經理和團隊其他成員應能夠注意到，并優(yōu)先解決這些問題。問題的優(yōu)先級大于任務。

比如，這里如果要更改設計，則面臨著前面的單元測試要重寫、這個類的所有代碼要重新組織。

 

此時，我們最終選擇改用靜態(tài)類的方式去做。這樣，我們關閉這個問題，因為我們已經做出了決策。

增加一個任務：重構，Db改用靜態(tài)類方式，不再從DbConnection繼承。

經過半小時的工作，這個任務完成，新寫的4個單元測試正常運行通過。由此，我們知道，由于有單元測試基礎，這種更改設計的決策，比較容易下決心。

 

如此，我們通過創(chuàng)建4個單元測試、從而創(chuàng)建三個構造方法，完成了這一組任務。過程中，根據進度，在Tfs團隊項目中將各項task的狀態(tài)分別由in progress 改為done。

看看，比較滿意吧？運行所有測試，通過。相關的任務，done。將代碼簽入到源代碼服務器，接著做剩下的其他工作…