我的TDD實踐(2)

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

　　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)會進行版本控制，簡而言之，如果你和某人同時改寫了同一個文件，一般情況下誰先提交到服務器上，第二個人就無法提交并報告文件沖突。)

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