[91大的TDD課程心得] TDD 精髓

當我接觸到 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