提起測試驅(qū)動開發(fā)(以下簡稱"TDD")，圈內(nèi)工程師對其都有一定程度的了解，TDD 的優(yōu)點也得到了普遍的認可。有研究機構(gòu)曾對微軟和 IBM 的八個開發(fā)小組進行了對照測試，結(jié)果發(fā)現(xiàn)使用了 TDD 的小組比未使用的小組在問題發(fā)生比例上減少了四至九成。在結(jié)對編程的相關(guān)實驗中，使用 TDD 的小組比未使用的小組在黑箱測試通過率上平均高出 18%，效果相當(dāng)明顯。
但反觀日常所接觸的實際工作中，對于 TDD 的使用并不多見，碼農(nóng)們對其價值也褒貶不一，網(wǎng)上甚至有大咖寫文章公開論述觀點來反對它，這又是為什么呢?前不久我剛好在融云的一個項目里小范圍實踐了一把，我就試著結(jié)合各方觀點，斗膽談?wù)勛约旱捏w會。
首先介紹一下什么是 TDD ，TDD 最早是由 Kent Beck 提出并在他的《Test-Driven Development By Example》一書中進行詳細闡述的(Kent Beck也是極限編程 Extreme Programming 概念的提出者)。書中所述：TDD 就是以測試作為開發(fā)過程的中心，要求編寫任何產(chǎn)品代碼之前，首先編寫用于定義產(chǎn)品代碼行為的測試，而編寫的產(chǎn)品代碼又要以使測試通過為目標(biāo)的軟件工程方法，目的是構(gòu)造簡單、清晰、高質(zhì)量的代碼。
測試是保證軟件質(zhì)量的重要手段，一個公司的研發(fā)部門通常都會有很大比例的測試團隊作為質(zhì)量保證的堅實后盾。那么作為開發(fā)人員是不是就可以只關(guān)心寫代碼的進度，編譯通過后再跑幾遍沒問題就提交代碼呢?這樣的程序在碰上初始條件稍有改變，或者壓力、并發(fā)等外部因素略有變化下會不會出現(xiàn)崩潰等問題呢?有的團隊會制定規(guī)章制度，要求給完成的代碼編寫測試用例，必須通過才可以提交。這或許能在一定程度上使情況得到改善，但實際效果真的有那么明顯么?我就聽過有人抱怨說，完成代碼后再寫測試用例是浪費時間，因為對邏輯走向已十分了解，測試自然不會有什么大的紕漏，有那個時間不如多寫幾行代碼，反正有測試團隊兜底。乍一聽似有道理，但仔細一想實則是在逃避責(zé)任，也在浪費公司資源。
那保證軟件質(zhì)量，有何良策呢？ 讓我們來看 TDD 是如何做的，前面說過 TDD 的精髓在于將測試前置，這看似微不足道的變化到底會帶來怎樣的化學(xué)反應(yīng)呢?
第一，能夠明確目的。 在動手編寫生產(chǎn)代碼之前，就得先想好這一部分邏輯的輸入輸出是什么，編寫滿足需求的測試用例，同時增加對需求的強化理解。舉個簡單的例子，與合作開發(fā)的同事對好需求，劃分好各自實現(xiàn)的邏輯塊，結(jié)果后續(xù)聯(lián)調(diào)時才發(fā)現(xiàn)一方理解錯了意思，之前的工作量就白費了。有了這提前編寫的測試代碼，就能邏輯層面再次明確目標(biāo)，避免語言文字上的誤解。在編寫代碼過程中，更容易做到心無旁騖，思緒不會亂飄，因為你的目標(biāo)就是編寫能通過測試用例的代碼。當(dāng)然這一過程可能會需要持續(xù)對測試目標(biāo)進行完善，即所謂的 TDD 微循環(huán)：測試 -> 實現(xiàn) -> 重構(gòu) -> 測試 ...
第二，強化了模塊與接口的概念。 再紛繁復(fù)雜的業(yè)務(wù)邏輯也能按功能、層級分為若干業(yè)務(wù)模塊，模塊與模塊之間通過接口(API)通信，做好這兩點的設(shè)計無形中也就降低了業(yè)務(wù)邏輯的耦合性，低耦合又是單元測試的前提條件。這樣操作等同于迫使開發(fā)者將接口的設(shè)計與低耦合性放在第一位去考慮。工作中在接到項目、明確需求后，如何分配任務(wù)往往非?？简瀳F隊人員的綜合能力，拆解顆粒度太粗容易造成邊界不明確;太細又牽扯過多精力，不易實施。但無論怎樣，模塊化和明確的接口設(shè)計是任務(wù)拆解得以順利實施的前提，對將來可能發(fā)生的重構(gòu)也是極好的。
第三，有利于任務(wù)的并行展開。 當(dāng)任務(wù)拆解分配到個人后，必然有些邏輯是需要前提輸入條件的，比如客戶端需要請求服務(wù)器，那么在編寫測試用例時就應(yīng)當(dāng)提供這樣的前提條件模擬，即 Mock 對象。目前流行的測試框架都帶有 Mock 組件，比如谷歌的 GTest/GMock。有了這些交互對象，無論處在業(yè)務(wù)流程的哪個階段，都可以馬上展開任務(wù)，隨時與上下游模塊進行聯(lián)調(diào)，同時利用各自的單元測試劃分 Bug 歸屬。如果這一步不提前進行，開發(fā)任務(wù)就要按順序進行，難免出現(xiàn)人員等待的情況。
第四，可以非常高效地進行重構(gòu)。 說起重構(gòu)，可以說稍大點的項目，因為需求的變化或者邏輯的更新，重構(gòu)在所難免。有些人就會心里發(fā)怵，生怕會引入新的 bug，甚至陷入重構(gòu)的泥潭。如果這時有了事前準(zhǔn)備好的測試用例，每重構(gòu)完一塊查看一下測試結(jié)果，就可化風(fēng)險于無形。
此外 TDD 還很多優(yōu)點，如快速反饋，測試用例即文檔，降低測試團隊負擔(dān)等等。聊完了優(yōu)點，接下來再看看網(wǎng)上大咖們對 TDD 的負面情緒都有哪些。
目前來看最集中的抱怨就是 TDD 會增加時間的投入。TDD 的優(yōu)勢是建立在高質(zhì)量測試用例這一前提下的，如果測試代碼寫的不夠好或者不夠全面就難以覆蓋所有功能點，而"測試 -> 實現(xiàn) -> 重構(gòu)" 的微循環(huán)也會帶來不少測試代碼的開發(fā)工作。對于新手來講，耽誤了時間，效果卻很有限，自然動力不足。即便是有信心能使用好 TDD 的團隊，很多時候它的付出回報比也依然不高，尤其在強調(diào)迭代速度的互聯(lián)網(wǎng)公司，根據(jù)時間、質(zhì)量、花費三者只能取其二的理論，多數(shù)情況下也只能舍棄一部分質(zhì)量來保證研發(fā)速度，何況有經(jīng)驗的團隊即使不用 TDD 也是能保證質(zhì)量損失在可控范圍內(nèi)的。
其他的抱怨來自 TDD 的規(guī)則太教條化，比如它的三大定律：
1. 在編寫不能通過的單元測試前，不可編寫生產(chǎn)代碼。
2. 只可編寫剛好無法通過的單元測試，不能編譯也算不通過。
3. 只可編寫剛好滿足以通過當(dāng)前失敗測試的生產(chǎn)代碼。
這一點關(guān)鍵看怎么理解，有個博主說的就很好 "Learn the rules, THEN break them." 一旦理解了定律所表達的真實含義，是可以根據(jù)實際情況靈活變通的。
下面來談?wù)剛€人對 TDD 一些膚淺的看法。
既然 TDD 是軟件工程的一種理論方法，那么就會有它的適用范圍，短平快的任務(wù)應(yīng)用空間不會太大，TDD 更適合一些大中型、需要長期維護的項目，最好團隊中能有 TDD 經(jīng)驗的人帶領(lǐng)，如果沒有可以去看看網(wǎng)上一些著名的開源項目是怎么編寫它的測試代碼的，學(xué)習(xí)高手寫的代碼，每看一次都非常受益。
另外極限編程的一些理念，比如 KISS (Keep It Simple, Stupid)，YAGNI (You Aren't Gonna Need It)與 TDD 結(jié)合起來也很值得玩味。這也不難理解，XP 和 TDD 本來就是一個人提出的理論。無論寫代碼還是寫測試用例，這些原則性的東西，最好能貫徹。
最后再說一些編程方面的經(jīng)驗吧，最近這個項目給我印象最深的就是斷言的使用。不僅是在測試用例中用來判斷結(jié)果與期望值是否相符，更多是要在程序的關(guān)鍵位置埋好斷言，將風(fēng)險扼殺在搖籃之中。比如開源代碼 WebRTC 在核心類的方法中就大量使用了斷言，判斷調(diào)用線程是否正確，關(guān)鍵值是否符合要求等。這類錯誤可能會在程序運行到后面某個點才暴露出來，相同原因?qū)е碌默F(xiàn)象多種多樣，如果不及時發(fā)現(xiàn)，會大大增加 Debug 的成本。
所以我的建議就是斷言要大膽的加，甚至允許在 Release 版本中的關(guān)鍵位置存在斷言，這樣用戶在反饋問題時，就能正確歸因，及時解決改進。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
