TDD測試驅(qū)動開發(fā)模式在軟件工程開發(fā)實踐中的辯證思考

謝宇飛++彭霖

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

【關(guān)鍵詞】TDD 測試驅(qū)動開發(fā) 軟件工程

TDD全稱Test Driven Development，中文翻譯為測試驅(qū)動開發(fā)，上世紀九十年代中后期發(fā)起于敏捷開發(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ǔ)和實踐模型。

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

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

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

1.1 TDD的理論模型

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

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

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

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

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

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

1.2.3 TDD在構(gòu)架上保證了簡潔高效的類、庫和API

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

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

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

2 TDD的實踐問題和發(fā)展方向

2.1 TDD的實踐問題

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

2.1.1 測試本身難以確定

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

2.1.2 測試范圍難以確定

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

2.1.3 測試目的難以確定

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

2.1.4 測試方向難以確定

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

2.2 TDD的發(fā)展方向

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

2.2.1 ATDD（Acceptance Test Driven Development）

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

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

2.2.2 UTDD（Unit Test Driven Development）

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

3 結(jié)語

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

參考文獻

[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]朱少民.敏捷測試的思考和新發(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#測試驅(qū)動開發(fā)[M].北京：清華大學(xué)出版社，2012.

作者簡介

謝宇飛，男，講師，軟件工程碩士，教學(xué)方向為計算機編程語言，研究方向為數(shù)據(jù)挖掘、智能計算。

作者單位

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