TDD測試驅(qū)動在軟件工程中的辯證思考

前言：想要寫出一篇引人入勝的文章？我們特意為您整理了TDD測試驅(qū)動在軟件工程中的辯證思考范文，希望能給你帶來靈感和參考，敬請閱讀。

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

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

TDD全稱TestDrivenDevelopment，中文翻譯為測試驅(qū)動開發(fā)，上世紀九十年代中后期發(fā)起于敏捷開發(fā)（AgileDevelopment）思想中的極限編程（Extremeprogramming）理念。由KentBeck在2002年出版的《TestDrivenDevelopment:ByExample》和DavidAstels在2003年出版的《Test-DrivenDevelopment:APracticalGuide:APracticalGuide》共同奠定了TDD的理論基礎(chǔ)和實踐模型。從正式提出至今，TDD模式一直存在著兩種不同的應(yīng)用觀點。一種觀點認為TDD模式是一種軟件工程規(guī)范而不是簡單的技術(shù)驗證，換而言之，TDD的基本思路就是通過測試來推動整個開發(fā)的進行，并不只是單純的測試工作。另一種觀點認為TDD是一種編程技術(shù)，目標是編寫干凈的代碼，極限編程三位創(chuàng)始人之一的RonJeffries（另兩位是KentBeck和WardCunningham）是這種觀點的主要支持者。這兩種觀點并沒有絕對的對與錯，在生產(chǎn)、教學實踐中體現(xiàn)出了它們在不同條件、環(huán)境下各自的價值。2004年DavidAstels的《TestDrivenDevelopment:ByExample》被翻譯成中文，TDD模式開始在我國傳播，并在2006年-2010年受到了計算機學界和信息產(chǎn)業(yè)界的普遍關(guān)注和廣泛討論。在這場實踐檢驗理論的討論中，學界和大企業(yè)普遍對TDD模式持認可態(tài)度，而中小企業(yè)普遍表示這種模式并不切實際。2011年，朱少民撰文《敏捷測試的思考和新發(fā)展》提出，TDD實踐還存在較大困難，有比較多的爭議，TDD模式進一步向ATDD、BDD等模式適應(yīng)性轉(zhuǎn)型，并提出測試開發(fā)模式應(yīng)向本源回歸，不拘泥于某種單一模式，應(yīng)該持續(xù)質(zhì)量反饋、持續(xù)改進方法、不斷解決問題。2014年，DavidHansson（RubyonRails與Instiki的創(chuàng)始人），在自己的個人網(wǎng)站發(fā)表文章《TDDisdead.Longlivetesting.》否定TTD模式在軟件工程領(lǐng)域的實踐意義，從而引發(fā)了大量的討論直至今天。下面關(guān)于TDD模式的優(yōu)勢和問題，我們通過正反兩方面辯證的來分析思考，應(yīng)該就能夠?qū)DD模式有一個更加理性和準確的認識。

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

1.1TDD的理論模型

TDD模式在理念上是以用戶需求為導向，通過各級各類測試確保所有的需求都能被照顧到，在代碼不斷增加和重構(gòu)的過程中，檢查所有的功能是否正確。從開發(fā)流程上來說，首先根據(jù)需求編寫一個測試，此時因為沒有實現(xiàn)該功能，所以運行這個測試可預知其失敗。然后編寫最少量的代碼不斷迭代重復，直到測試通過為止。最后，根據(jù)簡單代碼的重復情況和代碼之間的合理結(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.2TDD的優(yōu)勢特性

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

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

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

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

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

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

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

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

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

2.1TDD的實踐問題

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

2.1.1測試本身難以確定

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

2.1.2測試范圍難以確定

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

2.1.3測試目的難以確定

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

2.1.4測試方向難以確定

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

2.2TDD的發(fā)展方向

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

2.2.1ATDD（AcceptanceTestDrivenDevelopment）

驗收驅(qū)動測試開發(fā)，首先業(yè)務(wù)分析師或者測試工程師根據(jù)客戶需求編寫驗收測試用例，然后開發(fā)人員通過驗收測試來理解需求和驗收條件，并編寫實現(xiàn)代碼直到驗收測試用例通過。由于驗收方法和類型也是多種多樣的，所以根據(jù)驗收方法和類型的不同，ATDD其實是包含以軟件的行為為驗收標準的BDD（BehaviorDrivenDevelopment）、以特定的實例數(shù)據(jù)為驗收標準的EDD（ExampleDrivenDevelopment），以特征模型為驗收標準的FDD（FeatureDrivenDevelopment）、以WebServiceAPI消費者提出API契約來驅(qū)動API提供者開發(fā)API的CDCD（ConsumerDrivenContractDevelopment）等各種的實踐方法。

2.2.2UTDD（UnitTestDrivenDevelopment）

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

3結(jié)語

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

作者:謝宇飛 彭霖 單位:江西應(yīng)用技術(shù)職業(yè)學院