Nunit單元測試實踐

項目中經常遇到這樣的問題，寫好的模組，由於需求的變更，資料庫欄位進行了修改，邏輯也有些變更，於是乎，在一大堆代碼修改後，進行運行介面開始測試。無奈一次不可能寫對所有的邏輯，或者連字號都拼錯。尤其是做B/S系統的時候，調試好一個功能，往往花費你大量的時間。而且，有更改的話，還要重來一遍，如果遇上些關聯關係，調試測試就更加複雜了。並且，在項目做了N個模組後，又修改了一個功能，說實話，天知道其他邏輯是否產生BUG了沒，呵呵。

所以，引進單元測試還是很有必要的，合理使用，還是很能夠改進代碼品質。看似CODE的時間延長了，實際上卻大大的縮短了DEBUG時間，並且大大減少了修改功能影響其他方法的邊際相應。

如果做是比較好的實踐呢？

一般大家都使用Nunit,這個不難，隨便園子裡面、網上都能搜到很多入門文章，我也不在複述。只談談注意事項。

1.測試只需做到邏輯操作的測試、資料crud的測試就行了。前端ui資料的收集顯示不是Nunit做的。我們的任務是確保傳送給ui的資料是正確的就行了。

如圖，在標準的demo中，我只進行了bll和dal層的測試

2. 測試資料庫最好和平時使用的資料庫分開，因為平時的測試資料並不能很好的解決自動化測試的問題,如上圖，用app.config單獨進行了庫的配置（DEMO用的是同一個庫）

3.測試資料根據情況進行構造和清理

有時候資料需要清理，但有時候不需要，因為做分類測試的話，有些資料保留比較方便，因此，盡量使用[Test,Category("xx")] 進行分類

4.跟據模組來測試提高效率和測試效果

通過分類測試，更容易的看出某個模組的問題，有時候，單獨測試一個方法的資料並不能說明什麼問題

5.結合TestDriven.net讓你事半功倍，結合這類vs的add-in工具，測試變得更加方便了，nunit成了擺設，基本上開啟他是為了看到綠色的進度條來爽一把。