TDD測(cè)試驅(qū)動(dòng)開(kāi)發(fā)模式在軟件工程開(kāi)發(fā)實(shí)踐中的辯證思考

謝宇飛++彭霖

摘 要TDD測(cè)試驅(qū)動(dòng)開(kāi)發(fā)模式本世紀(jì)初興起以來(lái)，一直在爭(zhēng)論中前進(jìn)發(fā)展，支持者奉其為圭臬，反對(duì)者棄之如敝履。客觀來(lái)說(shuō)，TDD模式自有其優(yōu)勢(shì)，也有其問(wèn)題，在多年的開(kāi)發(fā)實(shí)踐中，提出了一系列分支開(kāi)發(fā)模式。在軟件工程開(kāi)發(fā)實(shí)踐中，一方面，要辯證的看待該技術(shù)模式的優(yōu)缺點(diǎn)，不能偏聽(tīng)偏信；另一方面，也要根據(jù)自身項(xiàng)目的組織結(jié)構(gòu)、資金配置、人力資源、時(shí)間要求來(lái)選擇開(kāi)發(fā)模式。

【關(guān)鍵詞】TDD 測(cè)試驅(qū)動(dòng)開(kāi)發(fā) 軟件工程

TDD全稱(chēng)Test Driven Development，中文翻譯為測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，上世紀(jì)九十年代中后期發(fā)起于敏捷開(kāi)發(fā)（Agile Development）思想中的極限編程（Extreme programming）理念。由Kent Beck在2002年出版的《Test Driven Development： By Example》和David Astels在2003年出版的《Test-Driven Development： A Practical Guide： A Practical Guide》共同奠定了TDD的理論基礎(chǔ)和實(shí)踐模型。

從正式提出至今，TDD模式一直存在著兩種不同的應(yīng)用觀點(diǎn)。一種觀點(diǎn)認(rèn)為T(mén)DD模式是一種軟件工程規(guī)范而不是簡(jiǎn)單的技術(shù)驗(yàn)證，換而言之，TDD的基本思路就是通過(guò)測(cè)試來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行，并不只是單純的測(cè)試工作。另一種觀點(diǎn)認(rèn)為T(mén)DD是一種編程技術(shù)，目標(biāo)是編寫(xiě)干凈的代碼，極限編程三位創(chuàng)始人之一的Ron Jeffries（另兩位是Kent Beck 和Ward Cunningham）是這種觀點(diǎn)的主要支持者。這兩種觀點(diǎn)并沒(méi)有絕對(duì)的對(duì)與錯(cuò)，在生產(chǎn)、教學(xué)實(shí)踐中體現(xiàn)出了它們?cè)诓煌瑮l件、環(huán)境下各自的價(jià)值。

2004年David Astels的《Test Driven Development： By Example》被翻譯成中文，TDD模式開(kāi)始在我國(guó)傳播，并在2006年-2010年受到了計(jì)算機(jī)學(xué)界和信息產(chǎn)業(yè)界的普遍關(guān)注和廣泛討論。在這場(chǎng)實(shí)踐檢驗(yàn)理論的討論中，學(xué)界和大企業(yè)普遍對(duì)TDD模式持認(rèn)可態(tài)度，而中小企業(yè)普遍表示這種模式并不切實(shí)際。2011年，朱少民撰文《敏捷測(cè)試的思考和新發(fā)展》提出，TDD實(shí)踐還存在較大困難，有比較多的爭(zhēng)議，TDD模式進(jìn)一步向ATDD、BDD等模式適應(yīng)性轉(zhuǎn)型，并提出測(cè)試開(kāi)發(fā)模式應(yīng)向本源回歸，不拘泥于某種單一模式，應(yīng)該持續(xù)質(zhì)量反饋、持續(xù)改進(jìn)方法、不斷解決問(wèn)題。2014年，David Hansson（Ruby on Rails與Instiki的創(chuàng)始人），在自己的個(gè)人網(wǎng)站發(fā)表文章《TDD is dead. Long live testing.》否定TTD模式在軟件工程領(lǐng)域的實(shí)踐意義，從而引發(fā)了大量的討論直至今天。下面關(guān)于TDD模式的優(yōu)勢(shì)和問(wèn)題，我們通過(guò)正反兩方面辯證的來(lái)分析思考，應(yīng)該就能夠?qū)DD模式有一個(gè)更加理性和準(zhǔn)確的認(rèn)識(shí)。

1 TDD的理論模型和優(yōu)勢(shì)特性

1.1 TDD的理論模型

TDD模式在理念上是以用戶(hù)需求為導(dǎo)向，通過(guò)各級(jí)各類(lèi)測(cè)試確保所有的需求都能被照顧到，在代碼不斷增加和重構(gòu)的過(guò)程中，檢查所有的功能是否正確。從開(kāi)發(fā)流程上來(lái)說(shuō)，首先根據(jù)需求編寫(xiě)一個(gè)測(cè)試，此時(shí)因?yàn)闆](méi)有實(shí)現(xiàn)該功能，所以運(yùn)行這個(gè)測(cè)試可預(yù)知其失敗。然后編寫(xiě)最少量的代碼不斷迭代重復(fù)，直到測(cè)試通過(guò)為止。最后，根據(jù)簡(jiǎn)單代碼的重復(fù)情況和代碼之間的合理結(jié)構(gòu)，考慮是否需要重構(gòu)代碼。簡(jiǎn)而言之，TDD是戴兩頂帽子思考的開(kāi)發(fā)方式：先戴上實(shí)現(xiàn)功能的帽子，在測(cè)試的輔助下，快速實(shí)現(xiàn)其功能；再戴上重構(gòu)的帽子，在測(cè)試的保護(hù)下，通過(guò)去除冗余的代碼，提高代碼質(zhì)量。測(cè)試驅(qū)動(dòng)著整個(gè)開(kāi)發(fā)過(guò)程：首先，驅(qū)動(dòng)代碼的設(shè)計(jì)和功能的實(shí)現(xiàn)；其后，驅(qū)動(dòng)代碼的再設(shè)計(jì)和重構(gòu)。如圖1所示。

1.2 TDD的優(yōu)勢(shì)特性

1.2.1 TDD在客觀上提升了代碼的質(zhì)量

技術(shù)人員編寫(xiě)剛好滿足需求又能通過(guò)測(cè)試的代碼，將代碼量和代碼本身的出錯(cuò)概率降至最低，客觀上保證了代碼的質(zhì)量。

1.2.2 TDD在主觀上要求了需求和開(kāi)發(fā)的一致

測(cè)試是以業(yè)務(wù)需求為導(dǎo)向，促進(jìn)了技術(shù)人員和業(yè)務(wù)客戶(hù)之間的交流，所有需求測(cè)試能夠通過(guò)，也即說(shuō)明業(yè)務(wù)功能全部滿足。

1.2.3 TDD在構(gòu)架上保證了簡(jiǎn)潔高效的類(lèi)、庫(kù)和API

由測(cè)試導(dǎo)向的功能調(diào)整，使得所有類(lèi)、庫(kù)和API都在圍繞快速實(shí)現(xiàn)功能來(lái)設(shè)計(jì)，并且實(shí)現(xiàn)后馬上測(cè)試，各項(xiàng)設(shè)計(jì)能夠馬上進(jìn)行調(diào)整。

1.2.4 TDD在開(kāi)發(fā)上促進(jìn)了代碼優(yōu)化重構(gòu)

通過(guò)各層級(jí)的測(cè)試，有助于從系統(tǒng)中清除大量累計(jì)產(chǎn)生的寄生代碼，整個(gè)開(kāi)發(fā)流程在測(cè)試、通過(guò)、重構(gòu)之間循環(huán)流轉(zhuǎn)，螺旋漸進(jìn)式的修正保證了代碼不斷優(yōu)化重構(gòu)，并且避免了遞歸錯(cuò)誤的出現(xiàn)。

2 TDD的實(shí)踐問(wèn)題和發(fā)展方向

2.1 TDD的實(shí)踐問(wèn)題

以上關(guān)于TDD相對(duì)于傳統(tǒng)軟件工程開(kāi)發(fā)先寫(xiě)功能再寫(xiě)測(cè)試的模式，無(wú)疑是具有先進(jìn)性的，但是事物的兩面性告訴我們，TDD模式也不是那么美好，更不是免費(fèi)的午餐。在IT行業(yè)的生產(chǎn)實(shí)踐中，特別是小微企業(yè)的實(shí)際開(kāi)發(fā)工作中，很多程序員們抱怨——“自從用了TDD，工作量更大了”。TDD模式對(duì)于技術(shù)人員，有太多難以確定的問(wèn)題，導(dǎo)致TDD模式難以使用、難以推廣，理論強(qiáng)、實(shí)踐弱的問(wèn)題比較突出。

2.1.1 測(cè)試本身難以確定

TDD是以需求為導(dǎo)向來(lái)確定測(cè)試，再以測(cè)試來(lái)規(guī)范功能開(kāi)發(fā)。這里的問(wèn)題就在于在開(kāi)發(fā)工作中，業(yè)務(wù)需求是不確定的，開(kāi)發(fā)最大的問(wèn)題恰恰是很多時(shí)候客戶(hù)自己都不確定需要什么樣的功能，大部分情況是由技術(shù)人員做個(gè)初略樣品，再由客戶(hù)提出修改意見(jiàn)，如此反復(fù)迭代，甚至客戶(hù)自己會(huì)經(jīng)常性推翻自己前期的需求，造成業(yè)務(wù)需求無(wú)從確定，也導(dǎo)致測(cè)試本身的確定就是個(gè)問(wèn)題。

2.1.2 測(cè)試范圍難以確定

TDD既然是測(cè)試規(guī)范功能，那么測(cè)試范圍就非常重要，太大會(huì)導(dǎo)致不知道錯(cuò)誤在哪，太小會(huì)導(dǎo)致測(cè)試變成了對(duì)應(yīng)的功能模塊，改改就能用，那還要測(cè)試干什么。所以好的TDD要求技術(shù)人員具有完備的測(cè)試用例的能力，這項(xiàng)能力需要豐富的理論與長(zhǎng)期的實(shí)踐，換而言之，能把TDD用好的人基本上是IT行業(yè)的高水平專(zhuān)家。那么這里出現(xiàn)了第一個(gè)模式悖論，如果使用門(mén)檻這么高、上手難度那么大，那么對(duì)于廣大中小技術(shù)團(tuán)隊(duì)、技術(shù)人員，TDD的推廣意義在哪里。endprint

2.1.3 測(cè)試目的難以確定

從表面看TDD測(cè)試的目的顯然是為了實(shí)現(xiàn)功能開(kāi)發(fā)，滿足業(yè)務(wù)需求，而在實(shí)際工作中，由于TDD強(qiáng)調(diào)以最少的代碼以滿足測(cè)試通過(guò)的思路，很容易致使測(cè)試通過(guò)成為測(cè)試的目的。當(dāng)大量的修改撲面而至，測(cè)試通過(guò)成為驗(yàn)證修改完成的主要指標(biāo)，那么為了測(cè)試而測(cè)試，就會(huì)取代為了功能而測(cè)試。

2.1.4 測(cè)試方向難以確定

在傳統(tǒng)的軟件開(kāi)發(fā)瀑布流模式中，開(kāi)發(fā)方向自上而下，一環(huán)扣一環(huán)，每一個(gè)環(huán)節(jié)都依賴(lài)于前面那個(gè)環(huán)節(jié)的正確性。那么TDD的方向只能依賴(lài)于不斷變化的需求，既然前置條件就是需求在不斷變化，那么誰(shuí)也確定不了后期的方向會(huì)和前期的方向一致，換個(gè)角度說(shuō)，就是誰(shuí)也無(wú)法保證前面的測(cè)試會(huì)適用與后面的功能。

2.2 TDD的發(fā)展方向

TDD模式在理論的美好和實(shí)踐的困難這對(duì)矛盾中不斷發(fā)展，為了增強(qiáng)其適用性和易用性，TDD逐步發(fā)展為ATDD與UTDD兩個(gè)分支模式。通不過(guò)不斷深化和細(xì)化測(cè)試模式，TDD已經(jīng)不再是一種技術(shù)標(biāo)準(zhǔn)，更體現(xiàn)了其業(yè)務(wù)規(guī)范的一面，也不再是一種方法，而更多的是一種在軟件開(kāi)發(fā)過(guò)程中的模式理念，構(gòu)成了一套更符合實(shí)際需求、更容易實(shí)踐掌握的敏捷測(cè)試框架。如圖2所示。

2.2.1 ATDD（Acceptance Test Driven Development）

驗(yàn)收驅(qū)動(dòng)測(cè)試開(kāi)發(fā)，首先業(yè)務(wù)分析師或者測(cè)試工程師根據(jù)客戶(hù)需求編寫(xiě)驗(yàn)收測(cè)試用例，然后開(kāi)發(fā)人員通過(guò)驗(yàn)收測(cè)試來(lái)理解需求和驗(yàn)收條件，并編寫(xiě)實(shí)現(xiàn)代碼直到驗(yàn)收測(cè)試用例通過(guò)。

由于驗(yàn)收方法和類(lèi)型也是多種多樣的，所以根據(jù)驗(yàn)收方法和類(lèi)型的不同，ATDD其實(shí)是包含以軟件的行為為驗(yàn)收標(biāo)準(zhǔn)的BDD（Behavior Driven Development）、以特定的實(shí)例數(shù)據(jù)為驗(yàn)收標(biāo)準(zhǔn)的EDD（Example Driven Development），以特征模型為驗(yàn)收標(biāo)準(zhǔn)的FDD（Feature Driven Development）、以Web Service API消費(fèi)者提出API契約來(lái)驅(qū)動(dòng)API提供者開(kāi)發(fā)API的CDCD（Consumer Driven Contract Development）等各種的實(shí)踐方法。

2.2.2 UTDD（Unit Test Driven Development）

單元驅(qū)動(dòng)測(cè)試開(kāi)發(fā)，首先將測(cè)試分為整體功能測(cè)試和功能模塊單元測(cè)試，編寫(xiě)一個(gè)功能測(cè)試，“編寫(xiě)代碼讓它通過(guò)”：編寫(xiě)一個(gè)或多個(gè)單元測(cè)試，然后進(jìn)入“單元測(cè)試 / 編寫(xiě)代碼”循環(huán)，直到單元測(cè)試通過(guò)為止。然后回到功能測(cè)試，查看是否有進(jìn)展，這一步還可以多編寫(xiě)一些應(yīng)用代碼，再編寫(xiě)更多的單元測(cè)試，如此一直循環(huán)下去。

3 結(jié)語(yǔ)

縱觀對(duì)TDD模式近十年來(lái)的爭(zhēng)論，也可以看成是理論派和實(shí)踐派之間的爭(zhēng)論，是大中企業(yè)和小微團(tuán)隊(duì)之間的分歧，更是無(wú)限神話和一味貶低之間的矛盾。技術(shù)、市場(chǎng)、需要一直在進(jìn)步和變化的當(dāng)下，任何一種開(kāi)發(fā)理論、開(kāi)發(fā)模式都不可能“一招鮮吃遍天”，盲目的吹捧某種技術(shù)神而明之，或一概否定某件事物的進(jìn)步之處，都是不實(shí)事求是的表現(xiàn)。TDD模式當(dāng)然不是萬(wàn)能鑰匙，一用就能馬上解決軟件開(kāi)發(fā)中的任何問(wèn)題，一種技術(shù)、理念、模式，只要它能夠不斷的發(fā)展、變革、修正，我們就應(yīng)該看到它先進(jìn)的地方和不足之處。至于某個(gè)具體項(xiàng)目需要什么樣的開(kāi)發(fā)模式，則要根據(jù)軟件工程項(xiàng)目的資金、人力、時(shí)間、組織等實(shí)際情況，進(jìn)行合理的選擇。

參考文獻(xiàn)

[1]Beck，K.Test Driven Development： By Example [M].Addison-Wesley Professional，2002.

[2]Astels，D.Test-Driven Development：A Practical Guide： A Practical Guide [M]. Prentice Hall，2003.

[3]Martin，R.C.Agile Software Development， Principles，Patterns， and Practices[M].Prentice Hall PTR，2002.

[4]Ambler，S.W.Introduction to Test Driven Development （TDD）[EB/OL]. [2017-6-30].http：//www.agiledata.org/essays/tdd.html.

[5]朱少民.敏捷測(cè)試的思考和新發(fā)展[J].程序員，2011（09）：37-40.

[6]Hansson，D.H.TDD is dead.Long live testing[EB/OL].（2014-4-23） [2017-6-30].http：//david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html.

[7]Percival，H.J.W.Test-Driven Development with Python 2e[M]. O'Reilly Media，Inc，USA，2017.

[8]賈洪峰，李菊彥.Bender，J， McWherter，J.C#測(cè)試驅(qū)動(dòng)開(kāi)發(fā)[M].北京：清華大學(xué)出版社，2012.

作者簡(jiǎn)介

謝宇飛，男，講師，軟件工程碩士，教學(xué)方向?yàn)橛?jì)算機(jī)編程語(yǔ)言，研究方向?yàn)閿?shù)據(jù)挖掘、智能計(jì)算。

作者單位

江西應(yīng)用技術(shù)職業(yè)學(xué)院 江西省贛州市 341000endprint