國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第 5 章 系統評估
5.1 案例研討
為說明所提出與實作之 BDD 整合測試平台將如何運作，本章以「紅利點數交換」的其 中一項功能為例，說明整個 BDD 整合測試平台將如何協助使用者開發與測試智能合約。
紅利點數交換為一個相度複雜度足夠的應用範例，在 Gherkin 的敘述中用到了大多 數的 Gherkin 語法（Given、When、Then、And），且在此範例中設計開發了多個智能合 約，並且一個智能合約對應到多個實例(instance)，使用此應用作為本篇論文的案例研討 為複雜度相對足夠，且亦不會過於複雜以至於難以理解。
首先，開發人員先與客戶(Stakeholders)討論業務需求。從客戶的描述得知其中一項 合約功能(Feature)為將點數於兩公司之間，以一定的規則與價值比率交換。此時，開發 人員首先在平台上開啟了一個新專案，並在 Gherkin IDE(圖 8)中，以 Feature Injection 方 式，基於 In order to /As /I want to 格式，寫作了如圖 30 的敘述。
圖 30: Feature Injection
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
接下來，開發人員開始依據細部功能敘述，定義情境(Scenario)與完成此 Scenario 所 需要進行的步驟(Step)，如圖 31。
圖 31: Scenario
圖 31 描述了一個 A 公司要和 B 公司交換點數的 Scenario。可看出該 Scenario 包含 了 6 個 Steps，在此無論 Given, And, When, 或 Then 都算是一個 Step。以 Company A exchange alp for blp 為例，意指將 A 公司點數(alp)交換成 B 公司點數(blp)。其第一個 Step 是 Given the exchange rate is 1 alp = 0.5 blp，意指此情境下的前提條件(Given)為 1 點 A 公司點數可換成 0.5 點 B 公司點數，第 2-3 個 Step 明確敘述了 A 公司與 B 公司之帳 戶初始值。第 4-6 個 When Step 敘述了當 A 之交換條件發生(When)時，A 公司與 B 公司 之帳戶餘額應有何種改變(Then)。在第 2-6 steps 都有以「<」與「>」括起來的變數，這 些變數在執行時，會以下方表格中提供的實際數值(稱為 Example)逐一代入變數中進行 測試。在 BDD 中，本研究稱有提 Example 的 Scenario 為 Scenario Outline。以圖 31 為 例，由於有 3 組不同 examples 可代入 5 個包括「<」與「>」括起來變數的 Steps，因此 共可產生 30 組不同的測試組合。以 BDD 的慣例來說，圖 30 和圖 31 的內容通常會寫在 同一份文件中，以.feature 的副檔名儲存，而其內容這種半結構化的規格敘述方式即為 Gherkin 格式。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 32: 在 StepDefs IDE 中發整合測試程式
寫作完 Gherkin 後，必須為每一個 Step 定義一個 Step Definition，Step Definition 本 質上為進行整合測試的程式碼(圖 32 )，以 JavaScript 撰寫，且可在 Step Defs IDE 中開 發(圖 32 )。
目前 Step Defs IDE 中尚未寫作 任何程式碼，但仍然可以進行第一次整合測試，當 然，初次整合測試因為尚未撰寫整合測試程式必會失 敗，此時整合測試工具中的 Integration Testing Service，它會呼叫底層的 Cucumber 進行測試) 會自動產生程式碼樣 版到 Step Defs IDE，開發人員可以根據此樣板開始寫作整合測試程式。基於整合測試工 具所產生的樣板，開發人員開始在 Step Defs IDE 中寫作整合測試程式碼。由於目前真 正的智能合約程式碼完全都還沒有開發，所以直覺上，開發人員會開始以「完成此整合 功能，並讓它們通過測試」的方式來思考寫出的程式碼，透過這種過程，開發人員會 發 現需要開發一到多個智能合約模組，且每個智能合約要提供一些方法 (methods)，才能 完成該整合測試。當開發人員開始寫作後，會發現若二家公司需要交換點數需要 A 公司 和 B 公司都有一個 Account(帳戶)合約，來維護 A 公司、B 公司目前各存有多少 A 公司 點數和 B 公司點數。雖然目前還沒實作 Account 合約細節，但以測試先行(Test-Driven) 的原則，可以透過寫作測試程式來推論出實際的合約模組需要那些欄位與方法。完成後，
開發人員可再度於 Step Defs IDE 中呼叫 Integration Testing Service 進行整 合測試，此
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
開發合約一樣以 TDD 方式進行，平台提供的合約單元測試介面稱為 Unit Test IDE，
提供開發人員線上寫作合約單元測試的場域。
圖 33: 在 UnitTests IDE 中撰寫單元測試程式
一個典型的合約單元測試範例如圖 33，由於開發人員發現 Account 中需要一個 addLoyaltyPoint 方法來為帳戶增加特定公司的紅利點數，因此在圖 33 中，先透過寫作 單元測試程式碼來規範 addLoyaltyPoint 方法的行為，接下可進行一次單元測試(會導致 失敗，因為尚未寫作合約)，下一步就是依此行為來實作合約(圖 34)。
圖 34: 以 Solidity 實作智能合約
實作完成智能合約後，透過 Contract Management Service 將智能合約部署至合約容 器(TestRPC)之後執行單元測試，若通過將給予測試通過之回饋，否則將給予錯誤之參考 資訊。若單元測試通過表示撰寫之智能合約所撰寫合約與其方法皆符合預期，此時可開 發下一組方法，直到讓圖 32 中的整合測試可通過為止。在圖 32 通過測試後，接下來依