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

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

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

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

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

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

也許有人會說，這兩點很矛盾，因為使用Mocking Framework會導(dǎo)致產(chǎn)生過多的測試設(shè)置。這就需要我們保持一個良好的平衡問題。

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

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

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

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

二、主張?zhí)嘣?

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

三、追溯編寫測試

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

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

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

四、測試過多代碼

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

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

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

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

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

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

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

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

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

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

寫在最后：

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

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

英文出自： NOtherDev