怎么理解TDD

本篇內容主要講解“怎么理解TDD”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么理解TDD”吧!

當前國內很多軟件開發人員對于TDD的理解比較模糊，大部分人也沒有明確和有意識的去實施TDD，應此很多人都有著不同的理解。

其中最經典的理解就是基于代碼的某個單元，使用Mock等技術編寫單元測試，然后用這個單元測試來驅動開發，抑或是幫助在重構、修改以后進行回歸測試。而現在大部分反對TDD的聲音就是基于這個理解，比如：

• 工期緊，時間短，寫TDD太浪費時間；

• 業務需求變化太快，修改功能都來不及，根本沒有時間來寫TDD；

• 寫TDD對開發人員的素質要求非常高，普通的開發人員不會寫；

• TDD 推行的最大問題在于大多數程序員還不會「寫測試用例」和「重構」；

• 由于大量使用Mock和Stub技術，導致UT沒有辦法測試集成后的功能，對于測試業務價值作用不大

• ......

總結一下，技術人員拒絕TDD的主要原因在于難度大、工作量大、Mock的大量使用導致很難測試業務價值等。

這些理解主要是建立在片面的理解和實踐之上，而在我的認知中，TDD的核心是：先寫測試，并使用它幫助開發人員來驅動軟件開發。

首先是先寫測試，這里的測試并不只是單元測試，也不是說一定要使用mock和stub來做測試。這里的測試就是指軟件測試本身，可以是基于代碼單元的單元測試，可以是基于業務需求的功能測試，也可以是基于特定驗收條件的驗收測試。

其次是幫助開發人員，主要是幫助開發人員理解軟件的功能需求和驗收條件，幫助其思考和設計代碼，從而達到驅動開發的目的，所以TDD是包含兩部分：ATDD與UTDD。

ATDD（Acceptance Test Driven Development）：驗收驅動測試開發，首先BA或者QA編寫驗收測試用例，然后Dev通過驗收測試來理解需求和驗收條件，并編寫實現代碼直到驗收測試用例通過。

由于驗收方法和類型也是多種多樣的，所以根據驗收方法和類型的不同，ATDD其實是包含BDD（Behavior Driven Development）、EDD（Example Driven Development），FDD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各種的實踐方法。

比如以軟件的行為為驗收標準，這個是BDD；如果以特定的實例數據為驗收標準，這個是EDD；如果以Web Service API消費者提出API契約來驅動API提供者開發API，這個是CDCD等。所以ATDD的具體實現需要結合項目的實際情況來選用適合的驗收測試方法與類型。

UTDD（Unit Test Driven Development）：單元驅動測試開發，首先Dev編寫單元測試用例，然后編寫實現代碼直到單元測試通過。這個就是現在很多人所謂的TDD、實踐的TDD、喜歡的TDD、抱怨的TDD，但是它卻只是真正意義上TDD的一部分而已。

TDD金字塔

再來看看David 的《TDD is dead. Long live testing》，他主要是認為TDD大量使用mock，導致無法測試軟件連接了數據庫之后的功能，進而無法測試其業務價值。

其次他提出應該使用”Long live testing”, 而他并沒有說明這種測試應該是在編寫代碼之前還是之后寫，以及會不會用來作為客戶對于軟件的驗收標準。如果他沒有這樣做，那他只是使用”Long live testing”來做回歸測試；如果他做了，那么他也是使用了ATDD，從而使用了TDD。

所以他對TDD的理解還是狹隘的，認為TDD只是UTDD，導致他寫了這篇文章來批評TDD。有可能他在現實工作中已經使用了ATDD，也就是TDD。

最后來看看Kent Beck、Martin Fowler、David關于Is TDD Dead?的辯論，我覺得他們所說的都有道理，并且也是合理的。原因是他們的背景和行業不同，本來對于不同的行業和不同的背景就應該選擇適合的測試驅動方法（有可能不一樣）。

首先來看看Kent Beck，他在Facebook工作，出版過很多書，可以定位為一名在大型IT公司工作的軟件思想家。其次是David，一個標準歐洲帥哥，ROR創造者之一，Basecamp公司的創始人和CTO，Basecamp是一個只有幾十個人的小型軟件公司，所以他可以定位是一名創業者、技術牛人。

Kent Beck所在的公司開發的是大型復雜業務軟件（Facebook平臺），代碼量巨大，需要長時間（幾年）大量人員（幾十甚至幾百）來開發和維護。DHH開發的中小型企業軟件（比如CRM），代碼量一般，需要快速（幾個月）、少量人員（幾個到十幾個）開發和維護。

• Kent Beck在金錢和人力資源相對充足、時間相對充裕的情況下追求的是代碼質量，大量人員的良好協作與平臺穩定。

• DHH卻在金錢和人力資源相對較少情況下追求最大化客戶業務價值，使得少量人員能快速開發出軟件并賣給客戶賺錢。

所以在Kent Beck所在的環境下，單元測試（UTDD）是非常有價值的；而在DHH所在的環境下，功能測試或者ATDD卻更為適合。

國內很多人對于TDD的狹隘理解還源于很多網上的中文資料，百度百科對于TDD的解釋就是其中一個：

TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產品代碼。TDD雖是敏捷方法的核心實踐，但不只適用于XP（Extreme Programming），同樣可以適用于其他開發方法和過程。

而國外有不少站點上的資料是對于TDD是有正確理解的，比如下圖是一個敏捷調查表。從其中的“We take a test-driven development(TDD) approach”和”We take a TDD approach at the requirements level”就能發現其對TDD的理解就是包含UTDD和ATDD。

TDD不是銀彈，不要期望它能解決任何問題，無論是UTDD、EDD還是BDD，根據自己項目的實際情況，比如資金、人力資源、時間、組織架構等，合理的選擇。  

到此，相信大家對“怎么理解TDD”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！