我是如何做測試驅動開發的:TDD實踐(4)

　　持續集成拓撲圖：

　　從實用性角度來說，持續集成避免了因為某人突然發生的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)

原文轉自：http://www.uml.org.cn/Test/201308201.asp