TDD測(cè)試驅(qū)動(dòng)在軟件工程中的辯證思考
前言：想要寫出一篇引人入勝的文章？我們特意為您整理了TDD測(cè)試驅(qū)動(dòng)在軟件工程中的辯證思考范文，希望能給你帶來靈感和參考，敬請(qǐng)閱讀。
摘要:tdd測(cè)試驅(qū)動(dòng)開發(fā)模式本世紀(jì)初興起以來，一直在爭(zhēng)論中前進(jìn)發(fā)展，支持者奉其為圭臬，反對(duì)者棄之如敝履?？陀^來說，TDD模式自有其優(yōu)勢(shì)，也有其問題，在多年的開發(fā)實(shí)踐中，提出了一系列分支開發(fā)模式。在軟件工程開發(fā)實(shí)踐中，一方面，要辯證的看待該技術(shù)模式的優(yōu)缺點(diǎn)，不能偏聽偏信；另一方面，也要根據(jù)自身項(xiàng)目的組織結(jié)構(gòu)、資金配置、人力資源、時(shí)間要求來選擇開發(fā)模式.
關(guān)鍵詞:TDD;測(cè)試驅(qū)動(dòng)開發(fā);軟件工程
TDD全稱TestDrivenDevelopment，中文翻譯為測(cè)試驅(qū)動(dòng)開發(fā)，上世紀(jì)九十年代中后期發(fā)起于敏捷開發(fā)（AgileDevelopment）思想中的極限編程（Extremeprogramming）理念。由KentBeck在2002年出版的《TestDrivenDevelopment:ByExample》和DavidAstels在2003年出版的《Test-DrivenDevelopment:APracticalGuide:APracticalGuide》共同奠定了TDD的理論基礎(chǔ)和實(shí)踐模型。從正式提出至今，TDD模式一直存在著兩種不同的應(yīng)用觀點(diǎn)。一種觀點(diǎn)認(rèn)為TDD模式是一種軟件工程規(guī)范而不是簡(jiǎn)單的技術(shù)驗(yàn)證，換而言之，TDD的基本思路就是通過測(cè)試來推動(dòng)整個(gè)開發(fā)的進(jìn)行，并不只是單純的測(cè)試工作。另一種觀點(diǎn)認(rèn)為TDD是一種編程技術(shù)，目標(biāo)是編寫干凈的代碼，極限編程三位創(chuàng)始人之一的RonJeffries（另兩位是KentBeck和WardCunningham）是這種觀點(diǎn)的主要支持者。這兩種觀點(diǎn)并沒有絕對(duì)的對(duì)與錯(cuò)，在生產(chǎn)、教學(xué)實(shí)踐中體現(xiàn)出了它們?cè)诓煌瑮l件、環(huán)境下各自的價(jià)值。2004年DavidAstels的《TestDrivenDevelopment:ByExample》被翻譯成中文，TDD模式開始在我國傳播，并在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è)試開發(fā)模式應(yīng)向本源回歸，不拘泥于某種單一模式，應(yīng)該持續(xù)質(zhì)量反饋、持續(xù)改進(jìn)方法、不斷解決問題。2014年，DavidHansson（RubyonRails與Instiki的創(chuàng)始人），在自己的個(gè)人網(wǎng)站發(fā)表文章《TDDisdead.Longlivetesting.》否定TTD模式在軟件工程領(lǐng)域的實(shí)踐意義，從而引發(fā)了大量的討論直至今天。下面關(guān)于TDD模式的優(yōu)勢(shì)和問題，我們通過正反兩方面辯證的來分析思考，應(yīng)該就能夠?qū)DD模式有一個(gè)更加理性和準(zhǔn)確的認(rèn)識(shí)。
1TDD的理論模型和優(yōu)勢(shì)特性
1.1TDD的理論模型
TDD模式在理念上是以用戶需求為導(dǎo)向，通過各級(jí)各類測(cè)試確保所有的需求都能被照顧到，在代碼不斷增加和重構(gòu)的過程中，檢查所有的功能是否正確。從開發(fā)流程上來說，首先根據(jù)需求編寫一個(gè)測(cè)試，此時(shí)因?yàn)闆]有實(shí)現(xiàn)該功能，所以運(yùn)行這個(gè)測(cè)試可預(yù)知其失敗。然后編寫最少量的代碼不斷迭代重復(fù)，直到測(cè)試通過為止。最后，根據(jù)簡(jiǎn)單代碼的重復(fù)情況和代碼之間的合理結(jié)構(gòu)，考慮是否需要重構(gòu)代碼。簡(jiǎn)而言之，TDD是戴兩頂帽子思考的開發(fā)方式：先戴上實(shí)現(xiàn)功能的帽子，在測(cè)試的輔助下，快速實(shí)現(xiàn)其功能；再戴上重構(gòu)的帽子，在測(cè)試的保護(hù)下，通過去除冗余的代碼，提高代碼質(zhì)量。測(cè)試驅(qū)動(dòng)著整個(gè)開發(fā)過程：首先，驅(qū)動(dòng)代碼的設(shè)計(jì)和功能的實(shí)現(xiàn)；其后，驅(qū)動(dòng)代碼的再設(shè)計(jì)和重構(gòu)。
1.2TDD的優(yōu)勢(shì)特性
1.2.1TDD在客觀上提升了代碼的質(zhì)量
技術(shù)人員編寫剛好滿足需求又能通過測(cè)試的代碼，將代碼量和代碼本身的出錯(cuò)概率降至最低，客觀上保證了代碼的質(zhì)量。
1.2.2TDD在主觀上要求了需求和開發(fā)的一致
測(cè)試是以業(yè)務(wù)需求為導(dǎo)向，促進(jìn)了技術(shù)人員和業(yè)務(wù)客戶之間的交流，所有需求測(cè)試能夠通過，也即說明業(yè)務(wù)功能全部滿足。
1.2.3TDD在構(gòu)架上保證了簡(jiǎn)潔高效的類、庫和API
由測(cè)試導(dǎo)向的功能調(diào)整，使得所有類、庫和API都在圍繞快速實(shí)現(xiàn)功能來設(shè)計(jì)，并且實(shí)現(xiàn)后馬上測(cè)試，各項(xiàng)設(shè)計(jì)能夠馬上進(jìn)行調(diào)整。
1.2.4TDD在開發(fā)上促進(jìn)了代碼優(yōu)化重構(gòu)
通過各層級(jí)的測(cè)試，有助于從系統(tǒng)中清除大量累計(jì)產(chǎn)生的寄生代碼，整個(gè)開發(fā)流程在測(cè)試、通過、重構(gòu)之間循環(huán)流轉(zhuǎn)，螺旋漸進(jìn)式的修正保證了代碼不斷優(yōu)化重構(gòu)，并且避免了遞歸錯(cuò)誤的出現(xiàn)。
2TDD的實(shí)踐問題和發(fā)展方向
2.1TDD的實(shí)踐問題
以上關(guān)于TDD相對(duì)于傳統(tǒng)軟件工程開發(fā)先寫功能再寫測(cè)試的模式，無疑是具有先進(jìn)性的，但是事物的兩面性告訴我們，TDD模式也不是那么美好，更不是免費(fèi)的午餐。在IT行業(yè)的生產(chǎn)實(shí)踐中，特別是小微企業(yè)的實(shí)際開發(fā)工作中，很多程序員們抱怨——“自從用了TDD，工作量更大了”。TDD模式對(duì)于技術(shù)人員，有太多難以確定的問題，導(dǎo)致TDD模式難以使用、難以推廣，理論強(qiáng)、實(shí)踐弱的問題比較突出。
2.1.1測(cè)試本身難以確定
TDD是以需求為導(dǎo)向來確定測(cè)試，再以測(cè)試來規(guī)范功能開發(fā)。這里的問題就在于在開發(fā)工作中，業(yè)務(wù)需求是不確定的，開發(fā)最大的問題恰恰是很多時(shí)候客戶自己都不確定需要什么樣的功能，大部分情況是由技術(shù)人員做個(gè)初略樣品，再由客戶提出修改意見，如此反復(fù)迭代，甚至客戶自己會(huì)經(jīng)常性推翻自己前期的需求，造成業(yè)務(wù)需求無從確定，也導(dǎo)致測(cè)試本身的確定就是個(gè)問題。
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è)的高水平專家。那么這里出現(xiàn)了第一個(gè)模式悖論，如果使用門檻這么高、上手難度那么大，那么對(duì)于廣大中小技術(shù)團(tuán)隊(duì)、技術(shù)人員，TDD的推廣意義在哪里。
2.1.3測(cè)試目的難以確定
從表面看TDD測(cè)試的目的顯然是為了實(shí)現(xiàn)功能開發(fā)，滿足業(yè)務(wù)需求，而在實(shí)際工作中，由于TDD強(qiáng)調(diào)以最少的代碼以滿足測(cè)試通過的思路，很容易致使測(cè)試通過成為測(cè)試的目的。當(dāng)大量的修改撲面而至，測(cè)試通過成為驗(yàn)證修改完成的主要指標(biāo)，那么為了測(cè)試而測(cè)試，就會(huì)取代為了功能而測(cè)試。
2.1.4測(cè)試方向難以確定
在傳統(tǒng)的軟件開發(fā)瀑布流模式中，開發(fā)方向自上而下，一環(huán)扣一環(huán)，每一個(gè)環(huán)節(jié)都依賴于前面那個(gè)環(huán)節(jié)的正確性。那么TDD的方向只能依賴于不斷變化的需求，既然前置條件就是需求在不斷變化，那么誰也確定不了后期的方向會(huì)和前期的方向一致，換個(gè)角度說，就是誰也無法保證前面的測(cè)試會(huì)適用與后面的功能。
2.2TDD的發(fā)展方向
TDD模式在理論的美好和實(shí)踐的困難這對(duì)矛盾中不斷發(fā)展，為了增強(qiáng)其適用性和易用性，TDD逐步發(fā)展為ATDD與UTDD兩個(gè)分支模式。通不過不斷深化和細(xì)化測(cè)試模式，TDD已經(jīng)不再是一種技術(shù)標(biāo)準(zhǔn)，更體現(xiàn)了其業(yè)務(wù)規(guī)范的一面，也不再是一種方法，而更多的是一種在軟件開發(fā)過程中的模式理念，構(gòu)成了一套更符合實(shí)際需求、更容易實(shí)踐掌握的敏捷測(cè)試框架。
2.2.1ATDD（AcceptanceTestDrivenDevelopment）
驗(yàn)收驅(qū)動(dòng)測(cè)試開發(fā)，首先業(yè)務(wù)分析師或者測(cè)試工程師根據(jù)客戶需求編寫驗(yàn)收測(cè)試用例，然后開發(fā)人員通過驗(yàn)收測(cè)試來理解需求和驗(yàn)收條件，并編寫實(shí)現(xiàn)代碼直到驗(yàn)收測(cè)試用例通過。由于驗(yàn)收方法和類型也是多種多樣的，所以根據(jù)驗(yàn)收方法和類型的不同，ATDD其實(shí)是包含以軟件的行為為驗(yàn)收標(biāo)準(zhǔn)的BDD（BehaviorDrivenDevelopment）、以特定的實(shí)例數(shù)據(jù)為驗(yàn)收標(biāo)準(zhǔn)的EDD（ExampleDrivenDevelopment），以特征模型為驗(yàn)收標(biāo)準(zhǔn)的FDD（FeatureDrivenDevelopment）、以WebServiceAPI消費(fèi)者提出API契約來驅(qū)動(dòng)API提供者開發(fā)API的CDCD（ConsumerDrivenContractDevelopment）等各種的實(shí)踐方法。
2.2.2UTDD（UnitTestDrivenDevelopment）
單元驅(qū)動(dòng)測(cè)試開發(fā)，首先將測(cè)試分為整體功能測(cè)試和功能模塊單元測(cè)試，編寫一個(gè)功能測(cè)試，“編寫代碼讓它通過”：編寫一個(gè)或多個(gè)單元測(cè)試，然后進(jìn)入“單元測(cè)試/編寫代碼”循環(huán)，直到單元測(cè)試通過為止。然后回到功能測(cè)試，查看是否有進(jìn)展，這一步還可以多編寫一些應(yīng)用代碼，再編寫更多的單元測(cè)試，如此一直循環(huán)下去。
3結(jié)語
縱觀對(duì)TDD模式近十年來的爭(zhēng)論，也可以看成是理論派和實(shí)踐派之間的爭(zhēng)論，是大中企業(yè)和小微團(tuán)隊(duì)之間的分歧，更是無限神話和一味貶低之間的矛盾。技術(shù)、市場(chǎng)、需要一直在進(jìn)步和變化的當(dāng)下，任何一種開發(fā)理論、開發(fā)模式都不可能“一招鮮吃遍天”，盲目的吹捧某種技術(shù)神而明之，或一概否定某件事物的進(jìn)步之處，都是不實(shí)事求是的表現(xiàn)。TDD模式當(dāng)然不是萬能鑰匙，一用就能馬上解決軟件開發(fā)中的任何問題，一種技術(shù)、理念、模式，只要它能夠不斷的發(fā)展、變革、修正，我們就應(yīng)該看到它先進(jìn)的地方和不足之處。至于某個(gè)具體項(xiàng)目需要什么樣的開發(fā)模式，則要根據(jù)軟件工程項(xiàng)目的資金、人力、時(shí)間、組織等實(shí)際情況，進(jìn)行合理的選擇。
作者:謝宇飛 彭霖 單位:江西應(yīng)用技術(shù)職業(yè)學(xué)院