讀處

撰寫產品程式碼之前寫單元測試，這種方法稱為測試驅動開發 (Test-Driven Development,TDD)

TDD的技術相當簡單

1.撰寫一個會失敗的測試，以證明產品中程式或功能的缺失。

2.撰寫符合測試預期的產品程式碼，以通過測試。(程式碼要盡可能簡單)

3.重構程式碼。

※重構意味著在不改變功能的前提下，修改程式碼，改善其可讀性、可維護性。

▲TDD示意圖，參考於《單元測試的藝術》P.18

TDD的三大法則:

第一法則 : 在撰寫一個單元測試(測試失敗的單元測試)前，不可撰寫任何產品程式。

第二法則 : 只撰寫剛好無法通過的單元測試，不能編譯也算無法通過。

第三法則 : 只撰寫剛好能通過當前測試失敗的產品程式。

對於我剛剛在描述TDD技術很簡單時，也許會有人覺得不同意

過往我們在使用傳統方式開發時，大多先進行寫產品程式碼，才進行單元測試

更何況有大多人都是有空才寫單元測試

因此可能覺得TDD這個方法很不切實際，相當困難執行

而在這邊我們就可以討論到TDD的背後具體含義

有的人說，就是因為都有人不寫測試，因此採用TDD就是強迫大量的測試

而對我而言，TDD這種開發方法不那麼直覺主要在於我過去開發習慣是先撰寫產品程式碼

導致讓我覺得先寫測試這件事相當抽象

關於這點，有人認為TDD就是一種設計程式的方法

許多人相信TDD的測試案例就是軟體的需求規格

而是否採用TDD這種方式進行開發，也許需要考量各種狀況後，團隊再自行決定即可