本文是《敏捷熱點(diǎn)問題的多角度雜議》（首次刊發(fā)在程序員雜志2011年9月刊）的一部分，為方便討論，在這里獨(dú)立成文。?

???? 在討論測試驅(qū)動開發(fā)之前，先澄清一個問題：測試驅(qū)動開發(fā)是否包括驗(yàn)收測試驅(qū)動開發(fā)。測試驅(qū)動開發(fā)（Test Driven Development，簡稱TDD）存在兩種理解：1，包括驗(yàn)收測試驅(qū)動開發(fā)（Acceptance Test Driven Develop，簡稱ATDD）在內(nèi)，這個是廣義的理解；2，TDD是采用單元測試手段，主要針對非界面代碼的，與用戶故事或需求一般沒有直接關(guān)聯(lián)，這個是狹義的理解，TDD和ATDD是并列的。多數(shù)人認(rèn)為應(yīng)當(dāng)采用第2種理解，主要因?yàn)?，TDD主要采用單元測試方法，典型工具有xUnit系列，ATDD主要采用界面自動化測試方法，典型工具有Selenium、QTP等；2，TDD主要用于設(shè)計(jì)和編碼，ATDD主要用于需求分析和確認(rèn)。下文TDD即是采用第2種理解的TDD。? ?

在極限編程（Extreme Programming，簡稱XP）中TDD是與簡單設(shè)計(jì)、重構(gòu)、持續(xù)集成等緊密配合的，這些組成了一套威力強(qiáng)大的組合裝備。TDD是其中最突出的外在表現(xiàn)，XP中TDD遵循“測試驅(qū)動開發(fā)金規(guī)”：先寫一個會失敗的測試，再寫一個新特征，永遠(yuǎn)如此。對比在武俠世界，XP的TDD（下文稱為極限測試驅(qū)動開發(fā)，英文為eXtreme Test Driven Development，簡稱為XTDD）屬于神器級別，功力不到者是沒法自如使用的，反而可能傷了自己。經(jīng)典的單元測試方法、架構(gòu)方法（比如常見的MVC）和設(shè)計(jì)方法（包括常用的設(shè)計(jì)模式）是開展TDD的基礎(chǔ)，TDD的學(xué)習(xí)和實(shí)施是循序漸進(jìn)的，由簡入繁的，由淺入深的。所以把XTDD可以看成是一個極端，把沒有任何單元測試視為第二個極端，把經(jīng)典軟件工程中V模型（其在單元測試方面的特征是針對已經(jīng)有的功能代碼編寫單元測試，以保障代碼的質(zhì)量）的完整單元測試看成第三個極端，三者組合為一個三角型，如圖一所示。從沒有任何單元測試到XTDD，存在多種多樣的中間狀態(tài)，比如只對模塊接口進(jìn)行TDD，比如進(jìn)行模塊級的架構(gòu)設(shè)計(jì)后開始TDD，比如在識別了主要類后再開始TDD，比如對個別有把握的模塊先編碼后加抽樣的單元測試，等等。在這個三角型中選擇一個合適的點(diǎn)，相信能夠發(fā)揮單元測試和TDD的最佳效果。在沒有足夠功力之前，先不必開展XTDD。簡單否定TDD是不恰當(dāng)?shù)摹?/span>

從CMMI角度看，TDD能夠滿足CMMI3級中技術(shù)方案過程域（TS）、驗(yàn)證過程域（VER）和產(chǎn)品集成過程域（PI）的多個實(shí)踐，是不錯的工程實(shí)踐。

從傳統(tǒng)的瀑布型生命周期方法及其衍生的V模型的角度看，TDD下的基本設(shè)計(jì)比較簡略，甚至沒有，難以滿足設(shè)計(jì)里程碑評審的要求，TDD沒有詳細(xì)設(shè)計(jì)，而單元測試各項(xiàng)指標(biāo)（比如覆蓋率、測試頻度、測試用例數(shù)量等）卻超過V模型，總體上違反了V模型。但是如果不了解源自于V模型下的單元測試技術(shù)、面向?qū)ο笤O(shè)計(jì)技術(shù)，TDD也是難以開展。

從XP角度看，TDD應(yīng)當(dāng)開展到極限。

從Scrum來看，TDD本身不屬于Scrum，應(yīng)當(dāng)由團(tuán)隊(duì)來決定是否采用TDD，如果是，也由團(tuán)隊(duì)來決定采用何種程度的TDD。

從ASD(Adaptive Software development)、FDD（Feature Driven Development）等其他敏捷方法流派來看，并沒有明確要求，根據(jù)需要來選擇開展TDD。

?

總結(jié)

以上是生活随笔為你收集整理的小议测试驱动开发的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。