前言

在歷史上有很多精彩絕倫的神仙打架，比如數(shù)學(xué)界的牛頓和萊布尼茨關(guān)于微積分的曠世之爭(zhēng)；比如量子物理中的愛因斯坦和波爾的紫禁之巔；比如足球里的梅西和C羅的旗鼓相當(dāng)難分高下；又比如滴滴和快滴之間觸目驚心的燒錢大戰(zhàn)……而在軟件行業(yè)中，也同樣有神仙打架的名場(chǎng)面，那就不得不提的是2014年的那場(chǎng)——測(cè)試驅(qū)動(dòng)開發(fā)（TDD）之爭(zhēng)。

比賽的紅方是David Heinemeier Hansson，藍(lán)方是Kent Beck。David Heinemeier Hansson 由于名字較長(zhǎng)簡(jiǎn)寫成DHH，Ruby on Rails 正是出自于DHH之手。而這場(chǎng)打架還加入了“裁判”員——Martin Fowler，在比賽中Martin Fowler記錄了紅藍(lán)雙方的每一次組合拳、上勾拳、側(cè)踹、抱摔……總結(jié)如下：

紅方DHH觀點(diǎn)

1.許多推動(dòng)TDD的開發(fā)人員會(huì)讓你覺得：如果你不使用TDD的話，你的代碼就是骯臟的。

2.由單元測(cè)試開始驅(qū)動(dòng)你的設(shè)計(jì)并不是一個(gè)好的主意。

3.TDD的概念“測(cè)試必須夠快”是目光短淺的。

4.對(duì)TDD的依賴會(huì)導(dǎo)致徹底忘記系統(tǒng)測(cè)試。

5.關(guān)注并且只關(guān)注單元模塊并不能有助于創(chuàng)建一套完美的系統(tǒng)。

6.100%的覆蓋率是愚蠢的。

7.程序員希望軟件是一門科學(xué)，可是它并不是。它更像是創(chuàng)造性的寫作活動(dòng)。

8.優(yōu)秀的軟件并不像工程學(xué)那樣，它更像寫作。清楚簡(jiǎn)潔的寫作要優(yōu)于復(fù)雜晦澀的寫作。

9.清晰是有好處的，好到應(yīng)該將清晰性作為第一目標(biāo)，而非測(cè)試覆蓋度或者測(cè)試速度。

10.成為一名優(yōu)秀的開發(fā)人員就像成為一名優(yōu)秀的作家一樣困難。

11.就像寫作一樣，成為優(yōu)秀的程序員的辦法就是以清晰為目標(biāo)從而大量編寫軟件、大量閱讀軟件。

藍(lán)方Kent Beck觀點(diǎn)

DHH已將TDD委托給歷史垃圾堆。我很難過(guò)，不是因?yàn)槲揖桶阉鼜臍v史的垃圾堆中拯救出來(lái)，而是因?yàn)楝F(xiàn)在我需要雇傭新技術(shù)來(lái)幫助我解決編程過(guò)程中的許多問(wèn)題：

1.過(guò)度工程化。我傾向于“投入”我“知道”我“將需要”的功能。使一個(gè)紅色的測(cè)試變?yōu)榫G色（以及未來(lái)的測(cè)試列表）有助于我實(shí)現(xiàn)足夠的功能。我需要找到一個(gè)新的方法來(lái)保持專注。

2.API反饋。我需要找到一種新的方法來(lái)獲得關(guān)于我的API決策的快速反饋。

3.邏輯錯(cuò)誤。我需要找到一種新的方法來(lái)抓住那些我很容易犯的討厭的測(cè)試錯(cuò)誤。

4.文檔。我需要找到一種新的方式來(lái)傳達(dá)我對(duì)api的期望，并記錄我在開發(fā)過(guò)程中的想法。

5.感到不知所措。我真的會(huì)懷念如何使用TDD，即使我無(wú)法想象一個(gè)實(shí)現(xiàn)，我?guī)缀蹩偰芟氤鋈绾尉帉憸y(cè)試。我需要找到一個(gè)新的方法，以便下一步上山。

6.將接口與實(shí)現(xiàn)思想分離。我傾向于用實(shí)現(xiàn)推測(cè)來(lái)污染API設(shè)計(jì)決策。我需要找到一種新的方法來(lái)分離這兩個(gè)層次的思維，同時(shí)在它們之間提供快速的反饋。

7.協(xié)議。我需要找到一個(gè)新的方法，精確地與一個(gè)編程伙伴關(guān)于我正在解決的問(wèn)題。

8.焦慮。也許我最懷念的是TDD給我的瞬間“一切都好嗎？”按鈕。

9.我相信我會(huì)找到其他方法來(lái)解決這些問(wèn)題。及時(shí)。疼痛會(huì)減輕的。再見TDD，老朋友。

神仙打架不虧是神仙打架，從那以后業(yè)界關(guān)于測(cè)試驅(qū)動(dòng)開發(fā)的觀念也分成了兩派。一派主要來(lái)源自像國(guó)內(nèi)的一些互聯(lián)網(wǎng)等項(xiàng)目中聲音——需求的迭代和更新之快，要求公司或團(tuán)隊(duì)能快速交付有價(jià)值的產(chǎn)品，而TDD對(duì)于很多開發(fā)人員來(lái)說(shuō)無(wú)疑是帶來(lái)了繁重的工作壓力和交付壓力。甚至有人開玩笑話說(shuō)：“ Deadline Driven Development 才是第一生產(chǎn)力 ”。

當(dāng)然也有人力挺TDD，“TDD并沒(méi)有死。很明顯，既然它有這么這么多的支持者，它怎么可能會(huì)死呢? 這就像在問(wèn)，設(shè)計(jì)模式死了嗎？或者功能性自動(dòng)化死了嗎？不，它并沒(méi)有死。而且它在將來(lái)任何時(shí)候都不會(huì)死亡。它將來(lái)可能會(huì)變成其他一些新的事物、甚至是一些更好的事物，但是它永遠(yuǎn)不會(huì)死亡。所以讓我們跳過(guò)這一部分吧?！?/p>

關(guān)于測(cè)試驅(qū)動(dòng)開發(fā)說(shuō)了這么久，那么測(cè)試驅(qū)動(dòng)開發(fā)到底是個(gè)啥呢？

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）是什么

測(cè)試驅(qū)動(dòng)開發(fā)，英文全稱Test-Driven Development，簡(jiǎn)稱TDD，是一種不同于傳統(tǒng)軟件開發(fā)流程的新型的開發(fā)方法。 它要求在編寫某個(gè)功能的代碼之前先編寫測(cè)試代碼，然后只編寫使測(cè)試通過(guò)的功能代碼，通過(guò)測(cè)試來(lái)推動(dòng)整個(gè)開發(fā)的進(jìn)行。 這有助于編寫簡(jiǎn)潔可用和高質(zhì)量的代碼，并加速開發(fā)過(guò)程。

Kent Beck：“測(cè)試驅(qū)動(dòng)開發(fā)不是一種測(cè)試技術(shù)。它是一種分析技術(shù)、設(shè)計(jì)技術(shù)，更是一種組織所有開發(fā)活動(dòng)的技術(shù)”。

分析技術(shù)： 體現(xiàn)在對(duì)問(wèn)題域的分析，當(dāng)問(wèn)題還沒(méi)有被分解成一個(gè)個(gè)可操作的任務(wù)時(shí)，分析技術(shù)就派上用場(chǎng)，例如需求分析、任務(wù)拆分和任務(wù)規(guī)劃等，《實(shí)例化需求》這本書可以給予一定的幫助作用。

設(shè)計(jì)技術(shù)： 測(cè)試驅(qū)動(dòng)代碼的設(shè)計(jì)和功能的實(shí)現(xiàn)，然后驅(qū)動(dòng)代碼的再設(shè)計(jì)和重構(gòu)，在持續(xù)細(xì)微的反饋中改善代碼。

組織所有開發(fā)活動(dòng)的技術(shù)： TDD 很好地組織了測(cè)試、開發(fā)和重構(gòu)活動(dòng)，但又不僅限于此，比如實(shí)施 TDD 的前置活動(dòng)包括需求分析、任務(wù)拆分和規(guī)劃活動(dòng)，這使得 TDD 具有非常好的擴(kuò)展性。

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的目標(biāo)

Kent Beck 在他的著作《Test-Driven Development》（見參考附錄）一書中提到：“代碼簡(jiǎn)潔可用這句言簡(jiǎn)意賅的話，正是 TDD 所追求的目標(biāo)”。

對(duì)于如何保證“代碼簡(jiǎn)潔可用”可以使用分而治之的方法，先達(dá)到“可用”目標(biāo)，再追求“簡(jiǎn)潔”目標(biāo)。

可用： 保證代碼通過(guò)自動(dòng)化測(cè)試。

代碼簡(jiǎn)潔： 在不同階段人們對(duì)簡(jiǎn)潔的理解程度也不一樣，不過(guò)遵循的原則差不多，例如 OOD 的 SOLID 原則（詳見參考附錄），Kent Beck 的 Simple Design 原則（詳見參考附錄）等。

雖然有很多因素妨礙我們得到整潔的代碼，甚至可用的代碼，無(wú)需征求太多意見，只需要采用 TDD 的開發(fā)方式來(lái)驅(qū)動(dòng)出簡(jiǎn)潔可用的代碼。

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的規(guī)則

在TDD 的過(guò)程中，需要遵循的三項(xiàng)原則：

1.在編寫好失敗的單元測(cè)試之前，不要寫任何產(chǎn)品代碼。

2.只要有一個(gè)單元測(cè)試失敗了，就不要再寫測(cè)試代碼。無(wú)法通過(guò)編譯也是一種失敗。

3.產(chǎn)品代碼恰好能夠讓當(dāng)前失敗的單元測(cè)試成功通過(guò)即可，不要多寫。

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的流程

測(cè)試驅(qū)動(dòng)開發(fā)是一個(gè)過(guò)程，依賴于不斷重復(fù)極短的開發(fā)周期，這個(gè)周期也稱為“紅燈-綠燈-重構(gòu)”，如上圖。簡(jiǎn)單的來(lái)說(shuō)，基于TDD的三項(xiàng)原則，TDD的這種步驟（周期）如下：

1.添加一個(gè)小的測(cè)試

2.運(yùn)行測(cè)試并查看失敗

3.對(duì)測(cè)試進(jìn)行微小的改動(dòng)通過(guò)測(cè)試

4.運(yùn)行所有測(cè)試并看到其通過(guò)

5.通過(guò)重構(gòu)去掉重復(fù)部分

需要注意的是，不同階段有不同的目的，他們需要不同的解決方案，前二個(gè)階段需要很快地完成，以便知道新添加功能的狀態(tài)。為了達(dá)成這個(gè)目的，可以通過(guò)任何手段，因?yàn)閮H在這時(shí)才這樣做，也是為了能快速完成好的設(shè)計(jì)。

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的好處

TDD主要的好處主要包括了，確定性、重構(gòu)代碼、單元測(cè)試即文檔。

確定性。TDD提升了單元測(cè)試的覆蓋率，在每輪迭代產(chǎn)品都會(huì)新增代碼，如果有一套覆蓋率很高（ 90% 或更高）的單元測(cè)試，那么只需執(zhí)跑一遍測(cè)試用例，那么能成功交付的把握就會(huì)比較大。反之，如果覆蓋率越低，越需要更多的人力去進(jìn)行手動(dòng)驗(yàn)證。 在 kent Beck的《測(cè)試驅(qū)動(dòng)開發(fā)》舉的例子中，正因有了TDD才有勇氣和老板說(shuō)我們可以做！這就是TDD最強(qiáng)大的地方，它讓你擁有一套值得信賴的測(cè)試，打消你對(duì)修改代碼的恐懼。

重構(gòu)代碼。Martin Flower在他的《重構(gòu)》中也指出，完善的單元測(cè)試是他進(jìn)行重構(gòu)的基石，從TDD的流程可以看到，重構(gòu)是TDD的一部分，運(yùn)用TDD的同時(shí)也推動(dòng)了代碼的重構(gòu)。

單元測(cè)試即文檔。在軟件行業(yè)里，人員的變動(dòng)的很頻繁的，如果要盡快熟悉某個(gè)模塊的業(yè)務(wù)邏輯?？次臋n？程序員寫的文章一般都不太容易看，而且文檔經(jīng)常會(huì)和代碼不同步，代碼修改了文檔沒(méi)跟著改的事情經(jīng)常發(fā)生?？丛创a？看完也不一定知道為什么。如果這時(shí)候有一套非常完整的單元測(cè)試，那可能就是所有接手別人代碼的程序員的福音。首先，代碼不會(huì)撒謊，其次，測(cè)試用例明確告訴了你這個(gè)函數(shù)是做什么的，什么輸入對(duì)應(yīng)的都有什么預(yù)期輸出。單元測(cè)試就是最好的底層文檔，哪個(gè)專業(yè)人士不想提供這樣一份文檔呢？

此外，TDD還能夠促成良好的代碼設(shè)計(jì)。由于你先寫測(cè)試代碼，你會(huì)盡可能的讓代碼調(diào)用起來(lái)更加簡(jiǎn)單方便，這也就促使你去考慮如何更好的設(shè)計(jì)代碼。以避免會(huì)出現(xiàn)一個(gè)函數(shù)里實(shí)現(xiàn)的功能過(guò)多，或者和其他代碼過(guò)于耦合而無(wú)法測(cè)試的情況。

當(dāng)然測(cè)試驅(qū)動(dòng)開發(fā)除了好處以外，還有神仙打架中紅方代表DHH所提出的一些問(wèn)題?？偨Y(jié)來(lái)看，關(guān)于TDD的爭(zhēng)議可以大致從這幾個(gè)方面來(lái)看，軟件開發(fā)應(yīng)該由什么來(lái)驅(qū)動(dòng)，測(cè)試的速度和覆蓋程度，以及設(shè)計(jì)思想層面等幾方面。從 辯證統(tǒng)一的角度來(lái)看，事物有兩個(gè)方面， TDD不一定能適用于所有的場(chǎng)景，同樣TDD的局限性在某些場(chǎng)景下也不見得是對(duì)的，如果想要能更好的適用于自身，不僅要拿捏好度的問(wèn)題還要以敏捷的思想來(lái)應(yīng)對(duì)問(wèn)題，比如不應(yīng)該盲目的制定100%或0%的測(cè)試覆蓋率，也不應(yīng)該固化開發(fā)步驟而不顧實(shí)際情況。

所以，在最后的神仙打架中，Kent Beck也表達(dá)了David的論述可能會(huì)讓TDD浴火重生、鳳凰涅槃的觀點(diǎn)，希望可以找到更加好的方法。但無(wú)論如何， 在我們實(shí)際工作中，不應(yīng)該因?yàn)槟承?觀點(diǎn)成為我們接受或者拒絕它的理由。正所謂大道甚夷，而民好徑，作為敏捷開發(fā)中的一項(xiàng)優(yōu)秀實(shí)踐來(lái)看，TDD只有在真正使用過(guò)后才能評(píng)價(jià)是否已死的問(wèn)題。那么你在踐行敏捷開發(fā)的時(shí)候，是否使用過(guò)TDD這種實(shí)踐呢，又或是踐行過(guò)其他一些敏捷開發(fā)的實(shí)踐呢，有沒(méi)有評(píng)測(cè)過(guò)你所在的項(xiàng)目中的敏捷開發(fā)的成熟度是如何的呢？

沒(méi)有那就對(duì)了！華為云的DevCloud專業(yè)服務(wù)正是為此而生！

針對(duì)不同的崗位提供了評(píng)估的能力，讓開發(fā)者可以對(duì)號(hào)入座，并基于你所在的崗位、技術(shù)得到客觀、全面、系統(tǒng)的測(cè)評(píng)以及名師般的學(xué)習(xí)引導(dǎo)?？靵?lái)訪問(wèn)專業(yè)服務(wù)平臺(tái)，通過(guò)個(gè)人能力評(píng)估，看看自己是什么水平吧！

以上就是淺談測(cè)試驅(qū)動(dòng)開發(fā)TDD之爭(zhēng)的詳細(xì)內(nèi)容，更多關(guān)于測(cè)試驅(qū)動(dòng)開發(fā)TDD之爭(zhēng)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！