l

2021年12月23日 星期四

無痛將驗收測試文件寫在測試案例中

Dec. 23 20:18~21:45

截圖 2021-12-23 下午9.42.42

▲新買的電腦還沒寫code先來寫部落格

 

前情提要

2017年Teddy寫過一系列關於行為驅動開發(Behavior-Driven Development,BDD)的文章,請參考以下列表:

  1. BDD(1):詳盡的文件就是可用的軟體
  2. BDD(2):大家來吃小黃瓜之Cucumber運作原理
  3. BDD(3):在Eclipse執行Cucumber-JVM
  4. BDD(4):第一個Cucumber-JVM範例,上集
  5. BDD(5):第一個Cucumber-JVM範例,下集
  6. 在IntelliJ IDEA使用Cucumber(上)
  7. 在IntelliJ IDEA使用Cucumber(下)
  8. BDD(6):讓Step找到Step Definition
  9. BDD(7):使用Transform讓稅金同時支援5%和0.05表達方式
  10. BDD(8):實作第一個開發票Scenario
  11. 在IntelliJ IDEA使用Cucumber(上)
  12. 在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》,書中有一個例子如下圖所示:

 

截圖 2021-12-23 下午8.59.19

▲圖1:Living Documentation書中範例

 

看到這個例子Teddy突然心中有感:「對了,就是這樣。應該要把Cucumber的feature file內容寫在程式碼中而不是與程式碼分離。」於是Teddy也試著修改ezKanban的測試案例看看效果如何,請參考下圖:

 

截圖 2021-12-23 下午9.26.24

▲圖2:修改後的ezKanban驗收測試案例

 

Teddy覺得直接在測試案例程式碼加上Given-When-Than說明文字讓測試案例清楚很多,也免去了原本Cucumber在feature file與step definition之間做binding的麻煩。

至於圖2中Scenario(), When(), WhenFailure()是怎麼來的?其實很簡單,原本Teddy以為書中用了什麼工具,但找了一下沒找到。後來想到,自己寫一個不就好了。程式很簡單,長成下面這樣:

截圖 2021-12-23 下午9.34.27

▲圖3:用來在測試案例中撰寫Given-When-Than說明文字的工具,算是一的超級簡單的DSL(domain specific language)

 

這種做法,與程式語言和工具都無關。絕大部分的高階語言要寫出圖3中的程式應該是幾分鐘就搞定的事。

 

***

 

友藏內心獨白:本篇在新買的第12代i9電腦上撰寫XD。

1 則留言:

  1. 想不到還可以再次遇到這個概念,4 年前小弟服務的公司就是導入此作法(工程 team 規模約 50+ 人,採用的語言剛好有現成工具可用),寫起來確實是滿爽的,但所需付出的代價不可不慎。

    我認為規則越多,弄起來就越麻煩(例如較陡的學習曲線、要較多人配合、每次都要多寫一點 code等)。帶來的好處是否能蓋過缺點,則要看企業的階段、專案性質、團隊文化等適不適合。

    就好比 Cucumber,我相信還是有公司團隊能夠執行的很好,但許多中小企業比起「做好 BDD」、可能更在乎明年的薪水能不能靠這次趕出的新功能賺起來,此時用容易卡關的工具就不是那麼理想。

    用 Given-When-Than 寫測試案例,我想到的潛在問題主要有兩個:

    1. 「規則越多,弄起來就越麻煩」的部分
    2. 因為 DSL 實作不完美 → 受到限制 → 必須搞各種 workaround → 測試案例反而更難閱讀理解、甚至有 false-negative

    實際上當初主導引入 Given-When-Than 的人,後來就跟我承認,因為這些問題最後也是寫得沒那麼爽了...

    但我還是覺得,這樣工具沒有絕對的好或不好,要看團隊適不適合。

    回覆刪除