寫在前面：

我的TDD實踐這幾篇文章主要是圍繞測試驅動開發所展開的，其中涵蓋了一小部分測試理論，更多的則是關注工具的使用及環境的搭建，做到簡單實踐先行，后理論專精的目的。

UnitTest單元測試

簡介

1. 單元測試

1.1 定義：“單元測試”就是針對一個“工作單元”的測試，一般意義上來講是針對一個基礎類進行輸入/輸出測試。與之相關的是集成測試，驗收測試等。這里指單純意義上的“單元測試”。

1.2 特征：

與其他代碼相隔離：單元測試只測試一件事，否則應該懷疑是否是測試內容有誤。

與其他開發人員隔離：保證最小化的變量影響單元測試，也就是控制變量法。逐漸形成了模擬框架以及依賴注入框架等輔助工具。

有針對性：要做有意義的測試，保證完成那些功能或方法。

可重復：單元測試的最大優勢就是可重復，這也是持續集成的意義所在。

可預測：單元測試保證的是---確定的輸入得到肯定的輸出。

2. 涵蓋內容

2.1 單元測試框架（UnitTest）：自從2005年TDD開始流行，框架和工具得到了迅猛的發展，這些框架允許定義測試代碼，控制測試的執行，還提供了一個應用程序運行測試，并在成功完成測試套件中的每個測試后給出報告。

2.2 模擬框架（Mock）：為了僅測試一個方法而不對其他發展產生影響或者被影響，產生了Mock框架。通過模擬另一個類的代碼來完成單元測試，同時又充分的隔離了另一個類的部分信息。

2.3 注入框架（inject）：為了充分隔離類內部使用的對象，一般采用構造注入的方式或者屬性注入的方式，都是將外部初始化好的對象導入進測試類，以進行隔離。

3. 工具比較

3.1 單元測試工具：

3.1.1 NUnit：目前.net最流行的工具，由JUnit發展而來，簡單易用。 官方網站

3.1.2 MSTest： 也十分的強大，同時也被多種自動編譯工具所支持，在VS2010中十分方便創建以及關聯測試測試類，使用方便。

這是兩個比較主要的測試框架，NUnit更新比較慢，但是開源。兩種工具語法標簽上大同小異，也都支持“Setup”和“Teardown”方便初始化共享對象。

3.2 模擬框架：

3.2.1 Rhino Mock：免費，使用簡單，功能強大。

3.2.2 Type Mock：使用中間語言（IL）在運行時以模擬實現來代替實際實現。商業產品。模擬對象不需要從接口集成，可以模仿第三方類庫。

3.2.3 Moq：社區支持，功能強大，使用簡單。Moq利用了lambda表達式。語法更具描述性。

3.3 注入框架：

3.3.1 Structure Map：開源容器框架，能夠自動模擬容器。

3.3.2 Unity：來自微軟設計與實踐群組。

3.3.3 Autofac：允許不采用XML文件的情況下進行配置。

“我的TDD實踐”系列之TDD概念篇

簡介

1. TDD概念

TDD（Test-Driven Development, 測試驅動開發）已經成為現代軟件開發中非常重要的概念之一。TDD以測試用例為指導要求開發人員，開發出符合測試用例的程序，然后通過測試用例對程序進行驗收，這被叫做“測試先行的開發”。通過，一個很小范圍的功能的開發---驗收過程，增加軟件的內部穩定性，從而在整體上保證了軟件的健壯性。這是與傳統軟件開發流程所不同的地方，也是傳統的軟件開發所達不到的一種軟件開發的“實踐方式”。

2. 發展歷程

2.1 瀑布開發之前：軟件工程的發展初期，由于計算機資源等諸多限制，軟件的規模很小，擁有設備的開發人員更多的趨向于“迭代”開發，獨立完成功能，然后在逐步完善，這是一種早期的迭代開發。

2.2 瀑布式開發： 隨著計算機硬件的提高以及高級語言的出現，開發人員逐漸擺脫硬件的束縛，而逐漸使用高級語言的特性，提高了移植性。有了這些，為大型軟件的開發奠定了基礎。一般定義一個相對大規模的軟件開發（2年或更多），需要經歷的一般過程是： 項目啟動---》需求分析---》架構設計---》代碼設計---》測試---》交付

缺點： 軟件測試時間長，每個過程需等待其他過程完成之后才能進行（效率低），成本高，難度大，修改影響范圍大。

瀑布式開發就像三峽的船閘一樣，每一步都只能等待上一步完成之后才能進行。

2.3 瀑布+迭代開發：單純瀑布開發的根本缺點是，需求分析是在項目開始之前，而不是在之中進行的，這就要求瀑布開發對最初的需求分析定位十分的準確，對可能的擴展預先估計的很好，但這幾乎是不可能的。這時，人們逐漸轉向”迭代“和”遞增“開發。這一概念就要求把大的瀑布模型分成幾個不同的小的瀑布階段，每完成幾個小的迭代然后進行大的迭代開發。這樣在一定程度上保證了，可變更性。但是從整體上來說還是典型的瀑布式開發，前后過程仍然受到制約?！?/p>

2.4 敏捷開發：業務的變化不可避免，所以軟件開發業必須能夠適應。包括但不限于：Scrum，XP（極限編程），FDD（功能驅動開發），Clear-Case，ASD（自適應軟件開發）。其中TDD屬于XP的一種，是從測試先行實踐中發展而來。

3. 敏捷開發共同特征及原則

價值觀：

個人與互動 》 流程與工具

可用的軟件 》 詳盡的文檔

與客戶合作 》 合約協商

響應變化 》 遵循計劃

特征：

它們都將團隊內部的交流放在首要位置。鼓勵不同團隊人員經常交流。特別是開發人員與測試人員，架構師與開發人員。

它們注重項目的透明性。如每周的例會，板報等等。

團隊成員是相互負責的，勇于承擔責任，不推卸責任。

開發人員沒有自己的代碼基，而團隊擁有完整的代碼基，每個人都對其負責。

工作是在短暫的開發周期中完成的，一般情況下為一周至兩周。

必須包含應對變化的能力。

一個系統的大致框架是提前定義好的，但是詳細設計要等實際安排功能開發計劃時才會進行。

4. TDD的優點

TDD從一開就保證了代碼的質量：鼓勵開發人員只開發”最小化“的代碼完成特定測試功能。

遵循SOLID原則： SOLID (單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉)---Wiki

TDD確保了代碼與業務需求之間的高度一致性。

TDD鼓勵創建更簡單，針對性更強的API

TDD鼓勵更多的溝通，與企業，與團隊內部。

TDD有助于清除冗余代碼

TDD提供了內置的回歸測試。

工具

工欲善其事，必先利其器。

對TDD而言，首先是整體設計，然后是功能設計，功能設計中通過編寫測試用例來驅動開發。在開發過程中最基本的，最重要的是單元測試。而單元測試工具就成為了爭論的熱點，本篇不想過多討論工具的取舍，這些可以參考同系列的其他文章。

TDD理論中很多工具是圍繞UnitTest展開的。

“我的TDD實踐”系列之SVN架設

1. 介紹：

本文主要是介紹Source control system（源文件管理系統），這是CI的基礎，當然你也完全可以用它只做數據存儲，并行開發，源代碼控制等等，這里就不詳細介紹了，網上有很多資料描述SVN以及源代碼管理，TFS也是一個不錯的選擇。

這里我選擇了Subversion+TortoiseSVN的選擇，因為開源以及應用廣泛，免費。

通常所說的SVN其實是分為2個部分的：

服務端Server：Subversion

客戶端Client：TortoiseSVN （廣泛引用，功能強大，操作簡單

a) 意義：

i. 提供獲取歷史版本功能，恢復錯誤版本之前的狀態?；虮容^版本之間的不同。

ii. 鎖定正在編輯的文件，訪問控制鎖定，防止提交沖突。（不同產品，實現功能略有不同。）

iii. 良好的版本管理、版本分發。

iv. 提供文檔，工具，測試，源代碼的一體化管理。

b) 權衡

說明：Centralized集中式管理 與 Distributed分布式管理（要是開源的建議可以分布式管理，反之集中式管理）

Transactional支持事務性與nontransaction不支持事務性（是否支持還原代碼版本，很重要。曾經的慘痛教訓告訴我，即使能回滾的情況下已經很鬧心何況不能還原數據。）　

File blocking文件鎖or non-file blocking非文件鎖定方式。（文件鎖定方式屬于樂觀鎖，即檢出時（checkout）有權限的人都可以獲取，但是提交時（checkin）會進行版本控制，簡而言之，如果你和某人同時改寫了同一個文件，一般情況下誰先提交到服務器上，第二個人就無法提交并報告文件沖突。）

2. 環境搭建

Server ：Subversion

Subversion官網 （建議下載1.6.x）

Client：TortiseSVN

目前，官網只有1.8.x 64位版本，請找到適合您的客戶端。

本文中建議配合Subversion請使用TortoiseSVN-1.6.8.19260-win32-svn-1.6.11版本

步驟Steps：

點擊Subversion安裝包，并將程序安裝到“指定目錄”（默認是C盤下），默認安裝后重啟。
安裝完成，測試是否安裝成功。
打開CMD程序，輸入 svnserve --help。沒有提示錯誤就是安裝成功。

3.SVN服務端配置：

a) 在CMD中輸入：sc create SVNService binpath= "C:\Program Files\Subversion\bin\svnserve.exe --listen-port 3691 --service -r D:\SVN\Server\RepositoryRoot" displayname= "SVNService" start= auto depend= Tcpip

其中C:\Program Files\Subversion\bin\svnserve.exe是安裝程序的路徑；D:\SVN\Server\RepositoryRoot是目標路徑，在此之前要提前創建好該目錄下的RepositoryRoot文件夾。

啰嗦一句，win7下要管理員權限，沒有權限會返回“失敗5：拒絕訪問”。

也可以用批處理的方式注入cmd命令。

成功后會返回： CreatServer 成功。

b) 啟動SVNService服務：（管理員權限）cmd 執行 net start SVNService （SVNService是上面定義的服務名稱）

c) 使用SVN集成命令（或TSVN創建），cmd-> input：svnadmin create D:\SVN\Server\RepositoryRoot（此路徑必須是服務開啟的路徑）。然后你會在此目錄下看到生成了很多文件，具體不一一介紹了，在這個文件夾中創建tags，trunk，branches文件夾。

d) 配置Svn服務端：

在conf文件夾下，

Svnserve文件修改如下：

anon-access = none

passwd文件修改如下：

[users]  

至此，服務端配置基本完成，更多的設置文件中有說明，或者去訪問SVN中文站，這里筆者要強調一下的是：SVN服務端和客戶端的版本要一致，不然可能會出現莫名其妙的錯誤。更有意思的是，您可以不建立SVN服務端而直接聯接Git的開源程序，但目前只支持只讀。

4.SVN客戶端配置：

a) 安裝TortoiseSVN-1.6.8.19260-win32-svn-1.6.11.exe?；径际悄J設置，安裝完之后可以更改語言。

b) 完成本地磁盤和Svn服務端磁盤的映射。

i. 在本地文件夾下右鍵---checkout---按照圖片上的設置（注意我是本地所以用localhost，IP可以跨機器訪問；我更改了端口3691，所以要顯示指明一下，要不然會出錯。），最后輸入passwd中的用戶名和密碼即可。（qq:229063661）

至此，SVN客戶端也配置完畢了，SVN的使用方法這里就不舉例了，網上資料非常豐富，而且大家也可以查看T-SVN的操作手冊，或者訪問SVN中文站獲得更多信息。

“我的TDD實踐”系列之CI持續集成

簡介

CI（Continuous Integration）持續集成，最重要的服務對象是TDD，它是一個集合概念，包括自動構建build項目，自動分析代碼，自動測試，自動郵件報告，自動預編譯檢查，自動發布等等，這些都圍繞一個中心詞“Auto”，當然它不能幫您自動完成代碼 ：）。所有這些操作，直接解放了項目管理者，每日構建集成（Build every day）將會很大程度上提高項目的穩定性，代碼的健壯性及隨時反饋。

持續集成經典定義：www.martinfowler.com/articles/continuousIntegration.html

持續集成是一種能讓團隊成員友好“集成”（integrate）工作的軟件開發實踐，通常每個人最少每日“集成”一次，也就是說每天都要進行大量的“集成”（multiple integrates per day）。每一次集成都被自動構建器（automated build including test）盡可能快的檢測集成錯誤。許多團隊開發者發現，這種方法極大的降低了團隊簡集成的問題，而且能讓團隊更快的開發出有凝聚力，結合力的軟件（cohesive software）?！?--- Martin Fowler　

持續集成拓撲圖：

從實用性角度來說，持續集成避免了因為某人突然發生的Bug，導致團隊的人員必須等待這個Bug被修復，持續集成每日集成則大大降低了這種事情發生的概率或者控制在一個合理發生Bug的時間內（一個工作日）。

1. 什么樣的集成“頻率”才是合理的？

2. 持續集成具體的優勢和劣質在哪里？

2.1. 可能出現的問題：

2.1.1. 增加了維護CI的成本：起初可能是要在配置環境上花費些功夫，但比起使用效率上以及代碼健壯性控制上，則CI更有意義。

2.1.2. 需求更改過于頻繁，功能復雜：TDD開發的一個原則是“盡可能用最簡單的代碼完成一個需求，不添加額外的功能，如果需求改變，則讓測試部通過，然后重構，即不要一次完成將來可能的任務，只注重當前”。

2.1.3. 增加軟硬件成本和團隊學習曲線（Study Curve）：同第一條定律，學習曲線則可根據團隊情況逐漸深化。

2.1.4. 團隊成員將不得不編寫測試和構建項目：有了這些團隊成員可以只關注編寫代碼和調試代碼，比起修復那些被測試人員發現的bug，更多的利用了Coder的個人才能。（啰嗦一句，本人曾深受過那些莫名其妙的bug所帶來的危害，有些還是由于其他人的改動導致的，這樣不得不F11跟蹤代碼來理解Bug產生的流程，絕大多數時刻是極其痛苦的。）

2.1.5. 舊項目是否能用CI: 即使舊項目中沒有單元測試，也可以用CI中的源代碼管理等諸多功能。這里除非有絕對的意義，否則也不建議在舊代碼的基礎上補充單元測試。

2.2. 應用CI的優勢：

2.2.1. 降低軟件風險提高軟件的質量：測試代碼覆蓋率越高，提供的穩定性就越高，建議代碼覆蓋率80%以上，所謂的二八原則?!

2.2.2. 增強項目的透明度：集成服務器持續的反饋集成信息，包括集成是否成功，Bug修復的時間，修復Bug的時間等。

2.2.3. 迅速構建：更快的發現問題，以及要求構建時間平均在1.9分鐘左右。

3. 持續集成相關工具介紹：

3.1. 源文件管理系統（Source file control system）：SVN ，TFS（VSS），Github。。。。

具體內容請參考，本系列的其他文章：請返回文章前言

3.2. 持續集成服務端（平臺）：

3.2.1. TFS Server：微軟一體化解決方案。

3.2.2. TeamCity：近些年流行起來的CI集成平臺，由JetBrains維護。

3.2.3. CruiseControl.Net: 老舊的平臺，腳本配置，06年更新過一回。

3.3. 單元測試工具：

MSTest，NUnit

具體內容請參考，本系列的其他文章：請返回文章前言

3.4. 代碼分析工具：

FxCop，StyleCop，Ncover

具體內容請參考，本系列的其他文章：請返回文章前言

3.5. 其他工具：

SandCastle文檔構建，Mock框架，Inject框架

具體內容請參考，本系列的其他文章：請返回文章前言

持續集成服務端搭建

本節主要敘述幾種持續集成服務端的搭建及其中一些小的細節上的說明，由于時間原因，沒有更深層次的說明更多的功能特性，這確實是不足之處，待今后有時間補充。

1. CruiseControl.Net(CC.net)：

a) 介紹：Thoughtworks旗下產品，免費，需配置腳本文件。

官網：http://confluence.public.thoughtworks.org/display/CC/Understanding+the+alternatives+to+CruiseControl

b) 安裝步驟：

i. 下載CCnet：http://sourceforge.net/projects/ccnet/?source=dlp

ii. 點擊安裝包，進行默認安裝。

iii. 安裝完之后，如果是默認安裝的話，在%Program Files%\CruiseControl.NET\server，找到文件ccnet.config并用記事本打開并編輯。

iv. 網上有很多配置文件，如下是我的配置文件，

c) 手動運行：在安裝程序中啟動CruiseControl.Net，驗證是否成功。

d) 日志文件在：D:\CI\ArtifactWork\buildlogs目錄下。

e) 查看相關記錄：http://localhost/ccnet（前提是請安裝IIS）

f) 客戶端使用CCTry 獲取反饋。

2. TeamCity

a) 介紹：簡而言之，小項目免費，大項目付費。Web配置代替腳本配置。

官網：http://www.jetbrains.com/teamcity/

拓撲圖：

b) 安裝步驟：

i. 下載：http://www.jetbrains.com/teamcity/download/download_thanks.jsp

ii. 默認安裝。（需更改端口防止沖突，選擇user account登錄）

iii. Web配置：

1. 配置視頻：http://www.jetbrains.com/teamcity/documentation/demos/installation_new/index.html

　　　　　　　http://www.jetbrains.com/teamcity/documentation/userguide.jsp

2. TeamCity在線文檔：http://confluence.jetbrains.com/display/TCD8/Configuring+General+Settings

3. 登錄配置網頁進行相關設置，http://localhost:8011/login.html（安裝時，更改了端口號為8011防止沖突）

3.1. 點擊 Create New Project

3.2. 點擊 Create build configuration。（也可先創建一個子項目，然后再新建一個配置）

3.3. 點擊左上角的 Create and attach new VCS root, 然后VCS 類型選擇SVN，如下配置：

3.4. 保存之后，繼續配置：

選擇自動構建的方式：選擇Microsoft Visual Studio，也可選擇其他的構建器，如MSBuild。

3.5. 增加一個Build Feature，這里可暫時不選擇，直接跳過此步驟：點擊網頁右側的導航欄，選擇第4步。

3.6. 在導航中點擊第5步：Build trigger

3.7. 這里已經完成了基本配置，更多高級選項請參考TeamCity官方資料。

3.Team Foundation Server(TFS)

a) 介紹：與VS2010集成，一體化解決方案，當然沒有免費的午餐。

官網：http://msdn.microsoft.com/zh-cn/vstudio/ff637362.aspx

拓撲圖：