測試驅動開發——讓你的代碼更簡潔

蓋房子時，工人師傅砌牆會先用樁子拉上吊線，以吊線爲基準，以使磚可以壘的筆直。而測試驅動開發也是如此，先寫一個測試，而後研發過程以此爲基準，只編寫能經過這個測試的功能代碼。

 

視頻地址：https://www.zentao.net/xp/test-driven-development-80325.html/?from=upbky

 

順序顛倒下，先壘磚，再拉吊線看牆面是否筆直，不直的話進行校訂。這個過程就像傳統的軟件開發流程，先寫功能代碼，而後進行測試，有錯誤再一點點修改，所以，會嚴重影響研發效率。

 

測試驅動開發的目標

代碼整潔可用，是測試驅動開發所追求的目標。但有不少因素會妨礙咱們獲得整潔的代碼，甚至是可用的代碼。

 

如何實現測試驅動開發？

1.  只有自動測試失敗時，咱們才重寫代碼；

2.  消除重複設計，優化設計結構

這兩條規則實際上也蘊含了開發過程當中所經歷的階段。 測試驅動開發的整個流程正是將目標拆分，先達到「可用」目標，再追求「簡潔」目標。

 

測試驅動開發的流程

1.  首先思考並編寫用於定義產品代碼 行爲的測試

2.  運行測試，發現新增的測試不能經過

3.  編寫適當夠用的代碼

4.  運行測試，直至測試經過

5.  重構代碼，以消除重複設計，優化設計結構

6.  運行測試，驗證重構是否引入新的錯誤，直至測試經過且無需再重構

7.  最後重複上述步驟

 

測試驅動開發實際上是戴兩頂帽子思考的開發方式：先戴上實現功能的帽子，在測試的輔助下，快速實現其功能；再戴上重構的帽子，在測試的保護下，經過去除冗餘的代碼，提升代碼質量。

 

測試驅動開發，要求測試能夠徹底自動化運行，在對代碼進行重構先後，必須運行測試。這有助於編寫簡潔可用和高質量的代碼，能快速響應變化，並加速開發過程。

 

測試驅動開發的三定律

定律一：在編寫不能經過的單元測試前，不可編寫生產代碼。

測試驅動開發主張「測試先行」，這意味着咱們必須先寫單元測試，而且該單元測試必然失敗，才能編寫生產代碼。

 

定律二：只容許編寫恰好可以致使失敗的單元測試，編譯失敗也屬於一種失敗。

測試驅動開發鼓勵「簡單設計」，以很小的增量進行開發，遇到設計問題時可以及時解決，不要指望一個測試能實現多個功能。

 

定律三：只容許編寫恰好可以使得失敗的單元測試經過的生產代碼。

簡潔，盡最大可能減小沒必要要的工做，也是敏捷基本原則之一。要避免盲目編寫未來有可能須要的代碼。

 

遵循了測試驅動開發的這三條定律，那全部代碼都是可測試的了。「可測試」的另外一個詞是「解耦」，爲了單獨測試模塊，必須將其分離，因此測試驅動開發強迫分離模塊，迫使你們建立更好、更少耦合的設計。

 

Kent  Beck最先在其極限編程方法論中，向你們推薦「測試驅動」這一最佳實踐。極限編程中全部實踐方法並非獨立的，而是相輔相成的。歡迎你們關注極限編程系列往期視頻，瞭解更多極限編程實踐方法。

 

更多精彩視頻分享：https://www.zentao.net/page/college.html/?from=upbky