解讀TDD的五大誤區

所謂TDD簡單地說就是如下兩個步驟：確保全部的需求都能被照顧到；在代碼不斷增長和重構的過程當中，能夠檢查全部的功能是否正確。本文咱們一塊兒來看下關於TDD的五大誤區。

TDD（全稱Test Driven Development）測試驅動開發，是一種軟件開發的流程，其由敏捷的「極限編程」引入。其開發過程是從功能需求的測試用例開始，先添加一個測試用 例，而後運行全部的測試用例看看有沒有問題，再實現測試用例所要測試的功能，而後再運行測試用例，查看是否有case失敗，而後重構代碼，再重複以上步 驟。

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

• 確保全部的需求都能被照顧到。
• 在代碼不斷增長和重構的過程當中，能夠檢查全部的功能是否正確。

原文做者Adam Bar在拜讀了 Bradley Braithwaite的文章後引起了一些思考，對此，他補充了對TDD的一些見解，列舉出TDD的五大誤區。如下是文章譯文： 

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

1、不要使用Mocking Framework VS.太多測試設置

也許有人會說，這兩點很矛盾，由於使用Mocking Framework會致使產生過多的測試設置。這就須要咱們保持一個良好的平衡問題。

測試代碼勢必會產生一些依賴關係，假若不使用Mocking framework，那麼咱們將沒法進行單元測試。這一點是確定的。

這裏例舉有關代碼測試和數據庫的 例子——咱們一般稱之爲集成測試、half-arsed測試，這也是測試查詢自己惟一可靠的方法。

可是，在大多數狀況下，咱們使用stubs，避免使用mocks——二者以前的區別很是重要。Mocks做爲一種行爲測試工具常被用來執行檢查過分使用的自定義測試，同一我的在同一時間編寫代碼，就如同檢查咱們剛剛故意建立的設計同樣。 TDD致使大量的Mock和Stub。Test Case並不必定是那麼容易的，若是你的Test Case中的Mock多是錯的，你須要重寫他們。也許你會說，就算是不用TDD，在正常的開發過程當中，咱們的確須要使用Mock和Stub。沒錯！的確是這樣的，不過，記住，咱們是在實現代碼後來決定什麼地方放一個Mock或Stub，而不是在代碼實現前幹這個事的。因此，TDD中，Test Case是開發中最重要的環節，Test Case的質量的問題會直接致使軟件開發的正確和效率。

 

咱們更加關注的是真實的驗證結果（stubs將帶給你不少幫助），而不是經過耦合來實現。 沒有什麼比維持一個測試套件和spaghetti-flavoured mock 裝置更糟糕的事了。

2、主張太多元素

在每次測試時主張有一個邏輯是很好的規則。即便它意味着調用幾個Assert，但對我來講，使用任何asserts 都是同等重要。

3、追溯編寫測試

大多數TDD的獲益方式，從實施前就可進行思考。好比： 寫測試須要成本，測試須要維護。

許多開發者認爲這不只這是通往幸福的路徑，還有關於負面的狀況及邊界值（boundary values ）。  此外，它還強烈支持KISS和YAGNI原則，這對於長期代碼庫來講很是重要。 

我我的比較喜歡使用TDD來配合檢測錯誤報告。經過從新建立失敗條件來編寫失敗的單元測試使得更容易，這將有助於隔離故障，分析根本緣由所在，這每每比在現實生活的狀況下重現 bug容易得多。追溯編寫測試只適用於集成測試中查找Bug。

4、測試過多代碼

這是一條放之四海而皆準的廣泛真理。

在利用單元測試核心代碼中我看到許多有價值部分。建立這些代碼我更多的是根據TDD原則建立而來（尤爲是沒有產生錯誤的代碼及沒有失敗的測試）。 

可是我並不把100% 的代碼覆蓋率做爲最終目標，由於這樣沒有任何意義。

我想，總會有至關多的代碼不僅是適用於單元測試，即協調/組織類型的代碼（咱們稱之爲組成節點將其做爲組成root的引用），它們須要一些依賴關係，經過調用幾種方法，把代碼從這裏移植到那裏，無需添加任何邏輯，而無需真正干擾數據。

因爲其沉重的mocks和stubs 的使用，這種編寫測試的代碼比代碼自己要複雜的多。Bradley的經驗法則對我來講：爲每個IF， And，Or，Case，For，While條件語句編寫一個單獨的測試，當全部分支/條件語句被覆蓋時，該代碼將會被徹底覆蓋。

5、TDD跟測試的關係 

測試是TDD的必然結果。若是團隊一直在實踐TDD，全部的代碼都會有相應的測試，全部的測試其實就是整個系統的腳手架。 TDD方式的開發是從寫測試開始的。

使用TDD時，功能開發老是實現溝通結束條件，也就是在何種狀況下，能夠認爲功能完成，這個結束條件是以測試體現的。

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

對於需求來講，TDD更能引導開發人員作出真正符合需求的東西，不會過渡開發。對於設計來講，TDD的實踐能幫你清理思路，但不能教會你作好的設計。對於質量來講，TDD保證全部的代碼都有測試覆蓋，確定能提升質量。 

 

寫在最後：

對此，有專家建議想要用TDD請首先學會測試的基本功，另外要養成沒有測試過的功能堅定不算結束的功能的習慣，這個習慣很重要。爲何TDD狂熱者可以report出極少數量的bug的緣由之一，就是養成常常性測試的習慣。

 

使用 TDD 的目的是高效的開發高品質的程序。若是發現 TDD 危及這個目標（沒有完美的開發模式，TDD也有自身的弱點和侷限），那麼請適當的妥協。（編譯/Rnifeasy）