TDD（全稱Test Driven Development）測(cè)試驅(qū)動(dòng)開發(fā)，是一種軟件開發(fā)的流程，其由敏捷的“極限編程”引入。其開發(fā)過程是從功能需求的測(cè)試用例開始，先添加一個(gè)測(cè)試用例，然后運(yùn)行所有的測(cè)試用例看看有沒有問題，再實(shí)現(xiàn)測(cè)試用例所要測(cè)試的功能，然后再運(yùn)行測(cè)試用例，查看是否有case失敗，然后重構(gòu)代碼，再重復(fù)以上步驟。

其理念主要是確保兩件事：

• 確保所有的需求都能被照顧到。
• 在代碼不斷增加和重構(gòu)的過程中，可以檢查所有的功能是否正確。

原文作者Adam Bar在拜讀了Bradley Braithwaite的文章后引發(fā)了一些思考，對(duì)此，他補(bǔ)充了對(duì)TDD的一些看法，列舉出TDD的五大誤區(qū)。以下是文章譯文： 

1. 即使沒有單元測(cè)試，也比有單元測(cè)試做的差要好。 （It's better to have no unit tests than to have unit tests done badly ）
2. 利用代碼測(cè)試能夠產(chǎn)生許多高效的代碼且代碼看起來更加可靠、實(shí)用。 

一、不要使用Mocking Framework VS.太多測(cè)試設(shè)置

也許有人會(huì)說，這兩點(diǎn)很矛盾，因?yàn)槭褂肕ocking Framework會(huì)導(dǎo)致產(chǎn)生過多的測(cè)試設(shè)置。這就需要我們保持一個(gè)良好的平衡問題。

測(cè)試代碼勢(shì)必會(huì)產(chǎn)生一些依賴關(guān)系，倘若不使用Mocking framework，那么我們將無法進(jìn)行單元測(cè)試。這一點(diǎn)是肯定的。

這里例舉有關(guān)代碼測(cè)試和數(shù)據(jù)庫的例子——我們通常稱之為集成測(cè)試、half-arsed測(cè)試，這也是測(cè)試查詢本身唯一可靠的方法。

但是，在大多數(shù)情況下，我們使用stubs，避免使用mocks——兩者之前的區(qū)別非常重要。Mocks作為一種行為測(cè)試工具常被用來執(zhí)行檢查過度使用的自定義測(cè)試，同一個(gè)人在同一時(shí)間編寫代碼，就如同檢查我們剛剛故意創(chuàng)建的設(shè)計(jì)一樣。 TDD導(dǎo)致大量的Mock和Stub。Test Case并不一定是那么容易的，如果你的Test Case中的Mock可能是錯(cuò)的，你需要重寫他們。也許你會(huì)說，就算是不用TDD，在正常的開發(fā)過程中，我們的確需要使用Mock和Stub。沒錯(cuò)！的確是這樣的，不過，記住，我們是在實(shí)現(xiàn)代碼后來決定什么地方放一個(gè)Mock或Stub，而不是在代碼實(shí)現(xiàn)前干這個(gè)事的。所以，TDD中，Test Case是開發(fā)中最重要的環(huán)節(jié)，Test Case的質(zhì)量的問題會(huì)直接導(dǎo)致軟件開發(fā)的正確和效率。

我們更加關(guān)注的是真實(shí)的驗(yàn)證結(jié)果（stubs將帶給你很多幫助），而不是通過耦合來實(shí)現(xiàn)。沒有什么比維持一個(gè)測(cè)試套件和spaghetti-flavoured mock 裝置更糟糕的事了。

二、主張?zhí)嘣?/b>

在每次測(cè)試時(shí)主張有一個(gè)邏輯是很好的規(guī)則。即使它意味著調(diào)用幾個(gè)Assert，但對(duì)我來說，使用任何asserts 都是同等重要。

三、追溯編寫測(cè)試

大多數(shù)TDD的獲益方式，從實(shí)施前就可進(jìn)行思考。比如： 寫測(cè)試需要成本，測(cè)試需要維護(hù)。

許多開發(fā)者認(rèn)為這不僅這是通往幸福的路徑，還有關(guān)于負(fù)面的情況及邊界值（boundary values ）。  此外，它還強(qiáng)烈支持KISS和YAGNI原則，這對(duì)于長(zhǎng)期代碼庫來說非常重要。 

我個(gè)人比較喜歡使用TDD來配合檢測(cè)錯(cuò)誤報(bào)告。通過重新創(chuàng)建失敗條件來編寫失敗的單元測(cè)試使得更容易，這將有助于隔離故障，分析根本原因所在，這往往比在現(xiàn)實(shí)生活的情況下重現(xiàn)bug容易得多。追溯編寫測(cè)試只適用于集成測(cè)試中查找Bug。

四、測(cè)試過多代碼

這是一條放之四海而皆準(zhǔn)的普遍真理。

在利用單元測(cè)試核心代碼中我看到許多有價(jià)值部分。創(chuàng)建這些代碼我更多的是根據(jù)TDD原則創(chuàng)建而來（尤其是沒有產(chǎn)生錯(cuò)誤的代碼及沒有失敗的測(cè)試）。 

但是我并不把100% 的代碼覆蓋率作為最終目標(biāo)，因?yàn)檫@樣沒有任何意義。

我想，總會(huì)有相當(dāng)多的代碼不只是適用于單元測(cè)試，即協(xié)調(diào)/組織類型的代碼（我們稱之為組成節(jié)點(diǎn)將其作為組成root的引用），它們需要一些依賴關(guān)系，通過調(diào)用幾種方法，把代碼從這里移植到那里，無需添加任何邏輯，而無需真正干擾數(shù)據(jù)。

由于其沉重的mocks和stubs 的使用，這種編寫測(cè)試的代碼比代碼本身要復(fù)雜的多。Bradley的經(jīng)驗(yàn)法則對(duì)我來說：為每一個(gè)IF， And，Or，Case，F(xiàn)or，While條件語句編寫一個(gè)單獨(dú)的測(cè)試，當(dāng)所有分支/條件語句被覆蓋時(shí)，該代碼將會(huì)被完全覆蓋。

五、TDD跟測(cè)試的關(guān)系 

測(cè)試是TDD的必然結(jié)果。如果團(tuán)隊(duì)一直在實(shí)踐TDD，所有的代碼都會(huì)有相應(yīng)的測(cè)試，所有的測(cè)試其實(shí)就是整個(gè)系統(tǒng)的腳手架。TDD方式的開發(fā)是從寫測(cè)試開始的。

使用TDD時(shí)，功能開發(fā)總是實(shí)現(xiàn)溝通結(jié)束條件，也就是在何種情況下，可以認(rèn)為功能完成，這個(gè)結(jié)束條件是以測(cè)試體現(xiàn)的。

實(shí)踐TDD時(shí)，寫代碼只有兩種目的：1. 讓一個(gè)失敗的測(cè)試通過。2. 在不添加新功能（也就是不需要添加新的測(cè)試）的前提下，讓代碼、結(jié)構(gòu)或者測(cè)試更加清晰、整潔、易懂。

對(duì)于需求來說，TDD更能引導(dǎo)開發(fā)人員做出真正符合需求的東西，不會(huì)過渡開發(fā)。對(duì)于設(shè)計(jì)來說，TDD的實(shí)踐能幫你清理思路，但不能教會(huì)你做好的設(shè)計(jì)。對(duì)于質(zhì)量來說，TDD保證所有的代碼都有測(cè)試覆蓋，肯定能提高質(zhì)量。 

寫在最后：

對(duì)此，有專家建議想要用TDD請(qǐng)首先學(xué)會(huì)測(cè)試的基本功，另外要養(yǎng)成沒有測(cè)試過的功能堅(jiān)決不算結(jié)束的功能的習(xí)慣，這個(gè)習(xí)慣很重要。為什么TDD狂熱者能夠report出極少數(shù)量的bug的原因之一，就是養(yǎng)成經(jīng)常性測(cè)試的習(xí)慣。

使用 TDD 的目的是高效的開發(fā)高品質(zhì)的程序。如果發(fā)現(xiàn) TDD 危及這個(gè)目標(biāo)（沒有完美的開發(fā)模式，TDD也有自身的弱點(diǎn)和局限），那么請(qǐng)適當(dāng)?shù)耐讌f(xié)。（編譯/Rnifeasy）

英文出自：NOtherDev