使用ezSpec落實行為驅動開發與實例化需求（8）：規範平行行為

March 24 21:45~23:14

▲圖1：電梯的規格範例

 

前言

ezSpec與Gherkin相關的基本功能已經介紹完畢，今天介紹一個Gherkin沒有的功能：「描述平行行為的規格」。

Gherkin的Given, When, Then, And, But這些Step依據它們出現在Scenario的先後順序依序執行，對於一些天生就具有平行處理能力的系統，例如在IoT（Internet of Things）系統中，多個sensor或device彼此之間都是獨立且平行執行。在這種情況下，用Gherkin就無法表達這些平行執行的行為。

三月初的時候實驗室一組研究IoT的學生跟Teddy介紹他們用python開發的工具—concurrentSpec，它擴充Gherkin語意讓開發人員撰寫並執行同步行為規格。原本Teddy開發ezSpec並沒有計畫要支援描述平行處理行為，聽完學生的介紹，覺得加上這個功能可以讓描述行為的語意變得更完整，因此花了點時間在ezSpec中支援這個功能。

***

平行運作行為的範例

請參考圖1，該例子節錄自 <Specifying Internet of Things Behaviors in Behavior-Driven Development: Concurrency Enhancement and Tool Support> 這篇論文，論文作者是實驗室IoT小組的成員以及Teddy的指導教授鄭老師。論文中提到一個描述電梯規格的例子，這個例子參考自 Jackson所寫的兩本書：《Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices》與《Problem Frames: Analysing and Structuring Software Development Problems》，圖1的中文敘述是請ChatGPT幫忙翻譯。

這個例子如果用標準的Gherkin執行，假設第29行執行失敗（無法打開緊急指示燈），測試案例就會停在第29，後面的assertion就不會被驗證。在電梯的例子中，這種行為很顯然是不正確的。因為就算29行與30行都失敗，只要第28行成功（電梯有停在最近的樓層），第39行就應該被檢查（電梯門要在五秒內打開）。

有些測試框架可以讓使用者設定：「就算某一個assertion失敗，測試案例還是持續執行」。但就算是採用這種方式來執行圖1的例子，最後結果還是可能錯誤。例如第28行失敗但第31行成功，這表示：「電梯沒有成功停在最近的樓層，但是電梯門最後卻打開了。」這顯然不是使用者所期待的行為。

怎麼用Gherkin描述同步行為？concurrentSpec提出一個很簡單的擴充方式：「在不增加Gherkin keyword的前提之下，將Given, When, Then當作同步執行群組的起頭，它們之後的And與But將會與它們同步執行。整個同步群族執行完畢之後，才會開始執行下一個同步群組。」換句話說，Given, When, Then彼此之間是循序執行，但它們之後若接著And或But，這些And/But將與它們平行執行。

此外，還可以指定每一個Step如果執行失敗，之後的Step是否要繼續執行。

***

用ezSpec描述圖1行為的程式如圖2所示，Teddy故意讓「打開緊急指示燈」與「取消該叫車請求」發生錯誤（839行與842行），但是這兩個Step如果發生錯誤，下一個Given/When/Then依然會繼續執行（因為指定ContinuousAfterFailure參數）。請注意，圖2中的Step執行順序如下，Given, When, Then, Then是循序執行，第一個Then與後面兩個And為平行執行。

• Given
• When
• Then, And, And (834、838、841行)：三個Step平行執行
• Then

圖2中有一個小細節要注意，就是要讓Scenario以平行的方式執行，必須呼要ExecuteConcurrently()。

▲圖2：用ezSpec描述電梯規格範例

 

圖3顯示圖2執行結果，可以看到兩個And執行失敗並沒有影響後續Then的執行。

▲圖3：圖2執行結果報表

***

電梯門打不開

Teddy修改一下電梯的Scenario，故意讓電梯沒有停在最近樓層，請參考圖4。

▲圖4：模擬電梯沒有停在最近的樓層。

 

修改後的Scenario執行結果如圖5，可以看到因為Then沒有加上ContinuousAfterFailure參數，所以整個同步執行群組執行完畢之後，就不會繼續執行下一個Step。

▲圖5：圖4執行結果報表

***

看到這裡鄉民們可能會想：「不管電梯有沒有停在最近樓層，我就是要執行最後一個步驟的檢查啊！」也可以，修改一下Then，幫它加上ContinuousAfterFailure，請參考圖6。

 

▲圖6：加上ContinuousAfterFailure參數，即使電梯未停妥也繼續執行後續驗證步驟

 

修改後的Scenario執行結果如圖7，如果系統行為真的如此，恭喜你，找到一個bug。什麼bug？電梯未停靠最近樓層，但電梯門卻打開了。

▲圖7：圖6執行結果報表

***

 

結論

如果鄉民們的系統與IoT系統類似，有著很明顯的平行行為，那麼標準的Gherkin語意就無法描述這些行為。借用concurrentSpec所擴充的Gherkin語意，可以在不增加Gherkin keyword的前提之下，使用ezSpec描述平行系統的行為。

ezSpec指定行為的功能差不多介紹完畢，下一集介紹ezSpec產生報表的功能。

***

友藏內心獨白：快到山頂了。