最近幾年“TDD已死”的聲音不斷出現(xiàn)，特別是David Heinemeier Hansson那篇文章——《TDD is dead. Long live testing. (DHH)》引發(fā)了大量的討論。其中最引人注目的是Kent Beck、Martin Fowler、David三人就這個(gè)舉行的系列對話(辯論)——Is TDD Dead?

[[185627]]

(圖片來自：image.slidesharecdn.com/)

當(dāng)前國內(nèi)很多軟件開發(fā)人員對于TDD的理解比較模糊，大部分人也沒有明確和有意識(shí)的去實(shí)施TDD，應(yīng)此很多人都有著不同的理解。

其中最經(jīng)典的理解就是基于代碼的某個(gè)單元，使用Mock等技術(shù)編寫單元測試，然后用這個(gè)單元測試來驅(qū)動(dòng)開發(fā)，抑或是幫助在重構(gòu)、修改以后進(jìn)行回歸測試。而現(xiàn)在大部分反對TDD的聲音就是基于這個(gè)理解，比如：

• 工期緊，時(shí)間短，寫TDD太浪費(fèi)時(shí)間;
• 業(yè)務(wù)需求變化太快，修改功能都來不及，根本沒有時(shí)間來寫TDD;
• 寫TDD對開發(fā)人員的素質(zhì)要求非常高，普通的開發(fā)人員不會(huì)寫;
• TDD 推行的***問題在于大多數(shù)程序員還不會(huì)「寫測試用例」和「重構(gòu)」;
• 由于大量使用Mock和Stub技術(shù)，導(dǎo)致UT沒有辦法測試集成后的功能，對于測試業(yè)務(wù)價(jià)值作用不大
• ......

總結(jié)一下，技術(shù)人員拒絕TDD的主要原因在于難度大、工作量大、Mock的大量使用導(dǎo)致很難測試業(yè)務(wù)價(jià)值等。

這些理解主要是建立在片面的理解和實(shí)踐之上，而在我的認(rèn)知中，TDD的核心是：先寫測試，并使用它幫助開發(fā)人員來驅(qū)動(dòng)軟件開發(fā)。

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

其次是幫助開發(fā)人員，主要是幫助開發(fā)人員理解軟件的功能需求和驗(yàn)收條件，幫助其思考和設(shè)計(jì)代碼，從而達(dá)到驅(qū)動(dòng)開發(fā)的目的，所以TDD是包含兩部分：ATDD與UTDD。

ATDD(Acceptance Test Driven Development)：驗(yàn)收驅(qū)動(dòng)測試開發(fā)，首先BA或者QA編寫驗(yàn)收測試用例，然后Dev通過驗(yàn)收測試來理解需求和驗(yàn)收條件，并編寫實(shí)現(xiàn)代碼直到驗(yàn)收測試用例通過。

由于驗(yàn)收方法和類型也是多種多樣的，所以根據(jù)驗(yàn)收方法和類型的不同，ATDD其實(shí)是包含BDD(Behavior Driven Development)、EDD(Example Driven Development)，F(xiàn)DD(Feature Driven Development)、CDCD(Consumer Driven Contract Development)等各種的實(shí)踐方法。

比如以軟件的行為為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是BDD;如果以特定的實(shí)例數(shù)據(jù)為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是EDD;如果以Web Service API消費(fèi)者提出API契約來驅(qū)動(dòng)API提供者開發(fā)API，這個(gè)是CDCD等。所以ATDD的具體實(shí)現(xiàn)需要結(jié)合項(xiàng)目的實(shí)際情況來選用適合的驗(yàn)收測試方法與類型。

UTDD(Unit Test Driven Development)：單元驅(qū)動(dòng)測試開發(fā)，首先Dev編寫單元測試用例，然后編寫實(shí)現(xiàn)代碼直到單元測試通過。這個(gè)就是現(xiàn)在很多人所謂的TDD、實(shí)踐的TDD、喜歡的TDD、抱怨的TDD，但是它卻只是真正意義上TDD的一部分而已。

TDD金字塔

再來看看David 的《TDD is dead. Long live testing》，他主要是認(rèn)為TDD大量使用mock，導(dǎo)致無法測試軟件連接了數(shù)據(jù)庫之后的功能，進(jìn)而無法測試其業(yè)務(wù)價(jià)值。

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

所以他對TDD的理解還是狹隘的，認(rèn)為TDD只是UTDD，導(dǎo)致他寫了這篇文章來批評TDD。有可能他在現(xiàn)實(shí)工作中已經(jīng)使用了ATDD，也就是TDD。

***來看看Kent Beck、Martin Fowler、David關(guān)于Is TDD Dead?的辯論，我覺得他們所說的都有道理，并且也是合理的。原因是他們的背景和行業(yè)不同，本來對于不同的行業(yè)和不同的背景就應(yīng)該選擇適合的測試驅(qū)動(dòng)方法(有可能不一樣)。

[[185629]]

(圖片來自：http://t.cn/RiHfT2q)

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

Kent Beck所在的公司開發(fā)的是大型復(fù)雜業(yè)務(wù)軟件(Facebook平臺(tái))，代碼量巨大，需要長時(shí)間(幾年)大量人員(幾十甚至幾百)來開發(fā)和維護(hù)。DHH開發(fā)的中小型企業(yè)軟件(比如CRM)，代碼量一般，需要快速(幾個(gè)月)、少量人員(幾個(gè)到十幾個(gè))開發(fā)和維護(hù)。

• Kent Beck在金錢和人力資源相對充足、時(shí)間相對充裕的情況下追求的是代碼質(zhì)量，大量人員的良好協(xié)作與平臺(tái)穩(wěn)定。
• DHH卻在金錢和人力資源相對較少情況下追求***化客戶業(yè)務(wù)價(jià)值，使得少量人員能快速開發(fā)出軟件并賣給客戶賺錢。

所以在Kent Beck所在的環(huán)境下，單元測試(UTDD)是非常有價(jià)值的;而在DHH所在的環(huán)境下，功能測試或者ATDD卻更為適合。

國內(nèi)很多人對于TDD的狹隘理解還源于很多網(wǎng)上的中文資料，百度百科對于TDD的解釋就是其中一個(gè)：

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

今天我們又聊了聊TDD，也希望大家重新理解一下，重新思考和嘗試一下，然后你會(huì)發(fā)現(xiàn)另外一片云彩。

TDD并沒有死，死的是你的持續(xù)學(xué)習(xí)、思考、實(shí)踐與總結(jié)。TDD其實(shí)早已融入日常的軟件開發(fā)工作中，只是很多人還沒有意識(shí)到。對于TDD的客觀必然存在性將在下一篇文章《讓我們再聊聊TDD 續(xù)——人人都在做TDD》中進(jìn)行介紹。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文