當我接觸到 Agile、XP (eXtreme Programming) 時
也常常聽見 TDD 這個名詞，在學習這門課前
僅約略知曉就是開發前先撰寫測試，以確保產品品質
心中不免晃過一絲絲「這只是測試人員推卸責任而已吧～」的念頭
（真的只有一絲絲喔～XD）
上完了第三天課，不只是顛覆既定的刻板思考
而是紮實有一種醍醐灌頂的感動。
很難描述這種感覺，抽象的來說～
大概就是掃地僧的那種 fu，前兩天就穩穩的練好掃地的基本功
第三天赫然發現這就是大招的起手式！而這大招完全就是破我之前瓶頸的那個檻！
扯完感想，回歸到 TDD 來～
談到 TDD，不外乎還是要從 Uncle Bob. 的 TDD 三大法則說起：
1.You are not allowed to write any production code unless it is to make a failing unit test pass.
2.You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3.You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
我的理解是：
1. 撰寫 Production Code 都要有其目的，而這個目的就是通過某個 unit test。
2. 完成一個 unit test 的撰寫後，請不要繼續著墨於其他 unit test，盡快撰寫 production code 讓它變成綠燈。
3. 若不是為了滿足當前的 unit test，一行 production code 也不要多寫。
所以整體流程就是：
1. 撰寫 Unit Test （紅燈）
2. 撰寫恰好可以通過此 Unit Test 的 Production Code（綠燈）
3. 重構 （接著返回1.，繼續描述下一個需求）
根據這樣的流程，可以很自然的達到簡單設計原則，完全沒有冗餘的程式碼。
為何簡單設計如此重要？
。缺乏可讀性、可測性、可維護性的程式碼可以透過重構逐漸修復，但若是 over design，完全是覆水難收。
。生下來的孩子，就有責任要照顧。每一行程式碼無形中都會增加維護成本，
別忘了，程式碼長度與 bug數量成正相關。
接下來，就是 TDD 最令我感動的部份。
在我介紹瀑布式開發與敏捷式開發的差異時，提到一段程式碼架構慣性的問題。
瀑布式開發的團隊將需求變更視為例外狀況，程式碼架構會採用預先最大需求的方式設計。
曾經有同事問過我，預先最大需求不是表示程式很彈性，什麼都考慮到了嗎？
不是也頗適合敏捷開發嗎？當時我只知道不太對勁，但很難講出個所以然～
聽完 TDD 這三大設計原則後，我完全明白了！！這鎖匙就是 TDD 所引導出的簡單設計原則啊！！
91大在課堂上舉了一個淺顯易懂的實例：倘若今天要開發一個計算各種會員等級回饋金的程式。
在傳統的開發邏輯下，會先開始設想軟體整體架構，而不同會員等級的回饋金計算方式只是架構中的一小部份
無論是哪個會員等級的計算功能，約莫會在同一時刻完成。
而用 TDD 的模式進行開發，可以先打通 MVP 的計算功能。此時此刻，這個 story 就已經可以交付。
可以更即時因應各種需求異動，符合敏捷開發的意涵。
僅用一張醜醜的圖作為結尾，表達我心中的畫面......XD
