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