使用ezSpec落實行為驅動開發與實例化需求（10）：撰寫自訂報表

March 25 12:44~14:18

▲圖1：ezSpec實作Visitor設計模式類別圖

 

前言

上一集介紹ezSpec的基本報表功能，這一集介紹如何擴充ezSpec，撰寫使用者自訂報表。

***

Visitor設計模式

為了支援自訂報表，ezSpec讓Gherkin keyword實作Visitor設計模式，請參考圖1。在GoF設計模式中，有兩個角色：

• Element：圖1中的SpecificationElement介面，要接受「拜訪者」的物件需要實做Element介面。該介面有一個accept方法，接受visitor作為參數。該方法的實作會呼叫（callback）visitor.visit，讓visitor可以讀取element的資料。
• Visitor：圖1中的SpecificationElementVisitor介面，想要拜訪各個Element的具體拜訪者（concrete visitor）需要實作該介面，將拜訪者的邏輯寫在visit方法裡面。在ezSpec中，客製化報表就是一個具體拜訪者。

 

圖2為Feature實作SpecificationElement介面的程式碼，第14行Feature先將自己傳給visitor，接著再將它身上每一個Story傳給visitor。由於Feature是整個Gherkin keyword中最外層的結構，只要拜訪Feature，就能夠拜訪整個Feature file裡面所有的元素，包含Scenario、Scenario、Background與Step。

▲圖2：ezSpec的Feature實作SpecificationElement的程式碼

 

***

 

實作SpecificationElementVisitor產生報表

ezSpec內建的文字檔報表，就是使用上述介紹的機制所產生，請參考圖3。第20行到60行的visit方法，就是用來「拜訪」Feature內的所有元素，產生報表的邏輯。

  

▲圖3：ezSpec內建產生文字報表的Visitor程式碼

 

***

客製化報表範例

開發好ezSpec之後，Teddy就拿它來描述ezKanban的規格。圖3為ezKanban的MoveLane使用案例的規格，用ezSpec的Scenario Outline撰寫。這個功能是將看板系統中，工作流程內部的某一個Lane複製到另一個地方。在描述規格的時候，直接以表格描述複製之前與複製之後Workflow的內容，其執行結果所產生的文字報表如圖4。

▲圖4：以ezSpec所撰寫的ezKanban系統之MoveLane使用案例規格 

 

圖5的內容不太容易閱讀，因為規格中表格還包含著另一個表格，因此Teddy想：「既然MoveLane使用案例是看板視覺化業務邏輯的其中一個功能，為什麼不用視覺化的方式來表達這個功能？」要怎麼用是視覺化方式產生報表，幫它寫一個Visitor吧，請參考圖5。

▲圖5：執行圖3所產生的ezSpec內建文字報表 

 

Teddy使用Markdown的Mermaid擴充（外掛）來繪製Workflow，圖6的WorkflowMermaidVisitor與ezSpec內建的PlainTextVisitor類似，差別在於前者針對MoveLane規格產生Markdown報表，後者則是標準的文字報表。

▲圖6：撰寫WorkflowMermaidVisitor產生MoveLane使用案例的專屬報表 

 

圖7報表的內容與圖4相同，前者以圖形顯示，後者以文字顯示。在MoveLane使用案例的情境中，以圖形顯示比較容易閱讀。

▲圖7：執行圖3所產生的客製化Markdown報表 

 

只要將寫好的Visitor在驗收測試的afterAll()方法中去拜訪Feature，再將結果寫入檔案中，就可以在每次執行驗收測試之後產生新的客製化報表，請參考圖8。

▲圖8：針對MoveLane使用案例驗收測試產生客製化報表

***

結論

寫到這裡剛好第十集，也把ezSpec目前的功能介紹完畢。Teddy預計在2023年七月之後開兩門新課：

1. Clean TDD（整潔測試驅動開發）
2. Living Documentation in Agile Development（敏捷開發中的活文件）

在課程中（特別是第二門課）會以ezSpec為範例，在開課前Teddy會先開源ezSpec讓有興趣的鄉民們使用，敬請期待。

***

友藏內心獨白：寫完文件要回頭寫Code。