第二，強(qiáng)化了模塊與接口的概念。再紛繁復(fù)雜的業(yè)務(wù)邏輯也能按功能、層級(jí)分為若干業(yè)務(wù)模塊，模塊與模塊之間通過(guò)接口（API）通信，做好這兩點(diǎn)的設(shè)計(jì)無(wú)形中也就降低了業(yè)務(wù)邏輯的耦合性，低耦合又是單元測(cè)試的前提條件。這樣操作等同于迫使開(kāi)發(fā)者將接口的設(shè)計(jì)與低耦合性放在第一位去考慮。工作中在接到項(xiàng)目、明確需求后，如何分配任務(wù)往往非?？简?yàn)團(tuán)隊(duì)人員的綜合能力，拆解顆粒度太粗容易造成邊界不明確；太細(xì)又牽扯過(guò)多精力，不易實(shí)施。但無(wú)論怎樣，模塊化和明確的接口設(shè)計(jì)是任務(wù)拆解得以順利實(shí)施的前提，對(duì)將來(lái)可能發(fā)生的重構(gòu)也是極好的。

第三，有利于任務(wù)的并行展開(kāi)。當(dāng)任務(wù)拆解分配到個(gè)人后，必然有些邏輯是需要前提輸入條件的，比如客戶端需要請(qǐng)求服務(wù)器，那么在編寫(xiě)測(cè)試用例時(shí)就應(yīng)當(dāng)提供這樣的前提條件模擬，即 Mock 對(duì)象。目前流行的測(cè)試框架都帶有 Mock 組件，比如谷歌的 GTest/GMock。有了這些交互對(duì)象，無(wú)論處在業(yè)務(wù)流程的哪個(gè)階段，都可以馬上展開(kāi)任務(wù)，隨時(shí)與上下游模塊進(jìn)行聯(lián)調(diào)，同時(shí)利用各自的單元測(cè)試劃分 Bug 歸屬。如果這一步不提前進(jìn)行，開(kāi)發(fā)任務(wù)就要按順序進(jìn)行，難免出現(xiàn)人員等待的情況。

第四，可以非常高效地進(jìn)行重構(gòu)。說(shuō)起重構(gòu)，可以說(shuō)稍大點(diǎn)的項(xiàng)目，因?yàn)樾枨蟮淖兓蛘哌壿嫷母拢貥?gòu)在所難免。有些人就會(huì)心里發(fā)怵，生怕會(huì)引入新的 bug，甚至陷入重構(gòu)的泥潭。如果這時(shí)有了事前準(zhǔn)備好的測(cè)試用例，每重構(gòu)完一塊查看一下測(cè)試結(jié)果，就可化風(fēng)險(xiǎn)于無(wú)形。

此外 TDD 還很多優(yōu)點(diǎn)，如快速反饋，測(cè)試用例即文檔，降低測(cè)試團(tuán)隊(duì)負(fù)擔(dān)等等。聊完了優(yōu)點(diǎn)，接下來(lái)再看看網(wǎng)上大咖們對(duì) TDD 的負(fù)面情緒都有哪些。

目前來(lái)看最集中的抱怨就是 TDD 會(huì)增加時(shí)間的投入。TDD 的優(yōu)勢(shì)是建立在高質(zhì)量測(cè)試用例這一前提下的，如果測(cè)試代碼寫(xiě)的不夠好或者不夠全面就難以覆蓋所有功能點(diǎn)，而“測(cè)試 -> 實(shí)現(xiàn) -> 重構(gòu)”的微循環(huán)也會(huì)帶來(lái)不少測(cè)試代碼的開(kāi)發(fā)工作。對(duì)于新手來(lái)講，耽誤了時(shí)間，效果卻很有限，自然動(dòng)力不足。即便是有信心能使用好 TDD 的團(tuán)隊(duì)，很多時(shí)候它的付出回報(bào)比也依然不高，尤其在強(qiáng)調(diào)迭代速度的互聯(lián)網(wǎng)公司，根據(jù)時(shí)間、質(zhì)量、花費(fèi)三者只能取其二的理論，多數(shù)情況下也只能舍棄一部分質(zhì)量來(lái)保證研發(fā)速度，何況有經(jīng)驗(yàn)的團(tuán)隊(duì)即使不用 TDD 也是能保證質(zhì)量損失在可控范圍內(nèi)的。

其他的抱怨來(lái)自 TDD 的規(guī)則太教條化，比如它的三大定律：

1. 在編寫(xiě)不能通過(guò)的單元測(cè)試前，不可編寫(xiě)生產(chǎn)代碼。

2. 只可編寫(xiě)剛好無(wú)法通過(guò)的單元測(cè)試，不能編譯也算不通過(guò)。

3. 只可編寫(xiě)剛好滿足以通過(guò)當(dāng)前失敗測(cè)試的生產(chǎn)代碼。

這一點(diǎn)關(guān)鍵看怎么理解，有個(gè)博主說(shuō)的就很好 “Learn the rules, THEN break them.” 一旦理解了定律所表達(dá)的真實(shí)含義，是可以根據(jù)實(shí)際情況靈活變通的。

下面來(lái)談?wù)剛€(gè)人對(duì) TDD 一些膚淺的看法。

既然 TDD 是軟件工程的一種理論方法，那么就會(huì)有它的適用范圍，短平快的任務(wù)應(yīng)用空間不會(huì)太大，TDD 更適合一些大中型、需要長(zhǎng)期維護(hù)的項(xiàng)目，最好團(tuán)隊(duì)中能有 TDD 經(jīng)驗(yàn)的人帶領(lǐng)，如果沒(méi)有可以去看看網(wǎng)上一些著名的開(kāi)源項(xiàng)目是怎么編寫(xiě)它的測(cè)試代碼的，學(xué)習(xí)高手寫(xiě)的代碼，每看一次都非常受益。

另外極限編程的一些理念，比如 KISS（Keep It Simple, Stupid），YAGNI（You Aren’t Gonna Need It）與 TDD 結(jié)合起來(lái)也很值得玩味。這也不難理解，XP 和 TDD 本來(lái)就是一個(gè)人提出的理論。無(wú)論寫(xiě)代碼還是寫(xiě)測(cè)試用例，這些原則性的東西，最好能貫徹。

最后再說(shuō)一些編程方面的經(jīng)驗(yàn)吧，最近這個(gè)項(xiàng)目給我印象最深的就是斷言的使用。不僅是在測(cè)試用例中用來(lái)判斷結(jié)果與期望值是否相符，更多是要在程序的關(guān)鍵位置埋好斷言，將風(fēng)險(xiǎn)扼殺在搖籃之中。比如開(kāi)源代碼 WebRTC 在核心類的方法中就大量使用了斷言，判斷調(diào)用線程是否正確，關(guān)鍵值是否符合要求等。這類錯(cuò)誤可能會(huì)在程序運(yùn)行到后面某個(gè)點(diǎn)才暴露出來(lái)，相同原因?qū)е碌默F(xiàn)象多種多樣，如果不及時(shí)發(fā)現(xiàn)，會(huì)大大增加 Debug 的成本。

所以我的建議就是斷言要大膽的加，甚至允許在 Release 版本中的關(guān)鍵位置存在斷言，這樣用戶在反饋問(wèn)題時(shí)，就能正確歸因，及時(shí)解決改進(jìn)。

【來(lái)源：網(wǎng)絡(luò)】

xiesc