現階段我們已經具備了新增跟移除商品的機制，然而要跟後端搭配的話就無法避免跟真實的 API 來進行串接，在測試環境中就不會那麼好處理。我們可以利用 Playwright 的 Mock API 機制來模擬我們想要的 API 回應。

延續現有的「加入購物車」功能，我們要繼續加入「移出購物車」的機制，因為原本的設計只是單純的滿足計數，這次還需要實現實際存在的商品列表來反應現實狀況。

我們現在已經準備好了可以使用 Cucumber 撰寫功能測試（Feature Test）的開發環境，接下來我們會用前端實作購物車的功能並且測試，然後接續實現後端完成一個具備非常基礎功能的前後端分離專案。

因為 Cucumber 是能夠跨越不同開發環境使用的，因此這次我們會以前端與後端互相搭配的方式進行，在前端的部分採用 Vite 和 Playwright 來進行測試。

Cucumber 的 Gherkin 語法本身並不複雜，然而除了步驟定義（Step Definition）之外，我們還可以加入輔助方法、標籤等等設定，讓我們的測試案例更加容易維護。

答案是肯定的，遊戲也是軟體的一種，善用軟體架構相關的思考對於設計遊戲仍然非常有幫助。今年的 Global Game Jam 因為隊友都比較熟悉 Unity，因此我也挑戰在 Unity 實踐去年沒有完善的部分。

使用 Cucumber 的 Gherkin 來撰寫測試是相當直覺的，然而這需要我們付出一些代價去實現「步驟定義」來將文件跟測試整合起來，然而這也是一個很好的機會讓我們去反思如何操作我們的軟體。

對功能描述之後，我們需要將詳細的步驟寫下來，讓 Cucumber 知道該怎麼做來檢查這個功能是否符合預期，因此我們可以使用 Given、When、Then 來進行描述。

Cucumber 的測試撰寫基本上是非常容易的，因為我們不是去配合程式來實現測試，而是直接去撰寫測試後，讓程式去配合測試。

在實際了解 Cucumber 的應用方式之前，我一直認為使用 Cucumber 撰寫測試是一件非常麻煩的事情，因為我們會需要實作許多 Step Definition（步驟定義）來讓文件中的某個行為可以被使用。

然而，當我了解到 Cucumber 的價值之後，就變成我優先選用的工具。