今年其實我比較少接活動 但這次受到老朋友的邀請
受邀去他們部門辦一場TDD的Workshop
這是個不錯的機會能夠將這些觀念播種在公司同仁身上
於是我就準備了約4小時的課程
開場我先田野調查一下 大家開發上碰到的問題
上半場是做一些基本的Unit Test介紹
對於比較進階的打破Dependency的部分也僅僅只有點到為止
但是我發現 大家對於這塊的問題真的很感興趣
下半場則是進入今天的主題 Coding Dojo
像往常一樣讓大家試試 略有陷阱的網球計分題
讓大家體驗一下 TDD的開發模式
或許是大家都是有經驗的工程師吧
這場Coding Dojo的模式跟過去幾場比較起來比較不熱絡
反倒是問了很多實務上的問題
以下紀錄一下幾個大家提出的問題
Q1 : Stub , Mock 與 Fake的差別 ？
A1 : Stub是模擬阻礙讓測試繼續進行的石頭
Mock比較間接 是驗證模擬對象是否預期 (你可以想成有一個函數是呼叫寄信的功能 但是我們無法驗證信到底有沒有寄到別人信箱 但是我們能有間接的方式得知到底有沒有呼叫到這個寄信函數)
Fake是指比較接近原生物件的取代物 我會覺得也有點像Stub 但是他的對象是原生的Library. 例如 .NET Framework的物件
Q2 : 寫Unit Test 開發速度會變慢 ？
A2 : 以我自己而言 開發速度的確會稍微慢一點 有些人說需要兩倍的時間 不過我倒覺得寫UT跟一再地用手測的時間可能不會差太多 但是可以省下後面很多整合, 解Bug的時間 以及Code的品質也會比較好
Q3 : 寫Unit Test會不會造成 QA Automation出現問題 ？ (註. 負負得正)
A3 : 其實這問題蠻奇怪的 我也想不出有什麼會負負得正的案例
不過用另一個角度想 負負得正不也代表 這東西其實是有問題的 但是automation沒抓出來？ 所以寫UT的效果能夠盡量讓狀態正正得正 不是才是正確的道路嗎？
Q4 : 用TDD的方式好像都沒有先想好大架構？這樣反而寫出不好的架構
A4 : 其實我自己還是會先有個初步的規劃與設計 但是TestCase仍是從需求那邊過來一步一步地建構 透過TDD的節奏 讓我能夠很快的檢視自己原本的規劃需不需要refactoring
Q5 : 專案太多Legacy Code 很多Dependency 怎麼辦？
A5 : 我不強求一定得先寫Unit Test, 所以碰到太多Dependency的就先建立一個範圍最大的一個測試 或許是Integration Test (這部分QA很厲害) 一旦測試開始建立起來 你就有信心去refactor裡面的東西 一個一個把dependency抽出來 並建立各自的Unit Test
