無痛將驗收測試文件寫在測試案例中
source link: http://teddy-chen-tw.blogspot.com/2021/12/blog-post.html?showComment=1640284807341
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
無痛將驗收測試文件寫在測試案例中
Dec. 23 20:18~21:45
▲新買的電腦還沒寫code先來寫部落格
前情提要
2017年Teddy寫過一系列關於行為驅動開發（Behavior-Driven Development，BDD）的文章，請參考以下列表：
當時學了一陣子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。
1 則留言:
想不到還可以再次遇到這個概念，4 年前小弟服務的公司就是導入此作法（工程 team 規模約 50+ 人，採用的語言剛好有現成工具可用），寫起來確實是滿爽的，但所需付出的代價不可不慎。
回覆
我認為規則越多，弄起來就越麻煩（例如較陡的學習曲線、要較多人配合、每次都要多寫一點 code等）。帶來的好處是否能蓋過缺點，則要看企業的階段、專案性質、團隊文化等適不適合。
就好比 Cucumber，我相信還是有公司團隊能夠執行的很好，但許多中小企業比起「做好 BDD」、可能更在乎明年的薪水能不能靠這次趕出的新功能賺起來，此時用容易卡關的工具就不是那麼理想。
用 Given-When-Than 寫測試案例，我想到的潛在問題主要有兩個：
1. 「規則越多，弄起來就越麻煩」的部分
2. 因為 DSL 實作不完美 → 受到限制 → 必須搞各種 workaround → 測試案例反而更難閱讀理解、甚至有 false-negative
實際上當初主導引入 Given-When-Than 的人，後來就跟我承認，因為這些問題最後也是寫得沒那麼爽了...
但我還是覺得，這樣工具沒有絕對的好或不好，要看團隊適不適合。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK