Dec. 23 20:18~21:45
▲新買的電腦還沒寫code先來寫部落格
前情提要
2017年Teddy寫過一系列關於行為驅動開發（Behavior-Driven Development，BDD）的文章，請參考以下列表：
- BDD（1）：詳盡的文件就是可用的軟體
- BDD（2）：大家來吃小黃瓜之Cucumber運作原理
- BDD（3）：在Eclipse執行Cucumber-JVM
- BDD（4）：第一個Cucumber-JVM範例，上集
- BDD（5）：第一個Cucumber-JVM範例，下集
- 在IntelliJ IDEA使用Cucumber（上）
- 在IntelliJ IDEA使用Cucumber（下）
- BDD（6）：讓Step找到Step Definition
- BDD（7）：使用Transform讓稅金同時支援5%和0.05表達方式
- BDD（8）：實作第一個開發票Scenario
- 在IntelliJ IDEA使用Cucumber（上）
- 在IntelliJ IDEA使用Cucumber（下）
當時學了一陣子Cucumber但後來一直沒有真正使用它。主要原因在於Teddy覺得「Cucumber將需求寫在feature file裡面，然後再轉成step definition程式碼，然後開發人員在這些step definition立面撰寫真正的測試邏輯」的這種流程不太流暢。完整開發一個功能，從寫feature file到寫完produciton code的過程會一直撞牆（卡住），尤其是feature file有參數要傳給step definition，真的不太直覺。
但當時Teddy也沒多想，就把這個問題放著。
＊＊＊
活文件
前幾天讀了《Living Documentation: Continuous Knowledge Sharing by Design》，書中有一個例子如下圖所示：
▲圖1：Living Documentation書中範例
看到這個例子Teddy突然心中有感：「對了，就是這樣。應該要把Cucumber的feature file內容寫在程式碼中而不是與程式碼分離。」於是Teddy也試著修改ezKanban的測試案例看看效果如何，請參考下圖：
▲圖2：修改後的ezKanban驗收測試案例
Teddy覺得直接在測試案例程式碼加上Given-When-Than說明文字讓測試案例清楚很多，也免去了原本Cucumber在feature file與step definition之間做binding的麻煩。
至於圖2中Scenario(), When(), WhenFailure()是怎麼來的？其實很簡單，原本Teddy以為書中用了什麼工具，但找了一下沒找到。後來想到，自己寫一個不就好了。程式很簡單，長成下面這樣：
▲圖3：用來在測試案例中撰寫Given-When-Than說明文字的工具，算是一的超級簡單的DSL（domain specific language）
這種做法，與程式語言和工具都無關。絕大部分的高階語言要寫出圖3中的程式應該是幾分鐘就搞定的事。
＊＊＊
友藏內心獨白：本篇在新買的第12代i9電腦上撰寫XD。
想不到還可以再次遇到這個概念，4 年前小弟服務的公司就是導入此作法（工程 team 規模約 50+ 人，採用的語言剛好有現成工具可用），寫起來確實是滿爽的，但所需付出的代價不可不慎。
回覆刪除我認為規則越多，弄起來就越麻煩（例如較陡的學習曲線、要較多人配合、每次都要多寫一點 code等）。帶來的好處是否能蓋過缺點，則要看企業的階段、專案性質、團隊文化等適不適合。
就好比 Cucumber，我相信還是有公司團隊能夠執行的很好，但許多中小企業比起「做好 BDD」、可能更在乎明年的薪水能不能靠這次趕出的新功能賺起來，此時用容易卡關的工具就不是那麼理想。
用 Given-When-Than 寫測試案例，我想到的潛在問題主要有兩個：
1. 「規則越多，弄起來就越麻煩」的部分
2. 因為 DSL 實作不完美 → 受到限制 → 必須搞各種 workaround → 測試案例反而更難閱讀理解、甚至有 false-negative
實際上當初主導引入 Given-When-Than 的人，後來就跟我承認，因為這些問題最後也是寫得沒那麼爽了...
但我還是覺得，這樣工具沒有絕對的好或不好，要看團隊適不適合。