關於 #測試 的內容

在開始實作後端之前，我們先將原本都集中在 src/App.vue 的程式碼整理一下。這個處理也可以在開發的過程中逐步重構，可以根據現況調整。

透過 Playwright 的 Mock API 機制，我們已經有了非常簡單的後端整合機制，接下來我們要繼續加上結帳的按鈕並且模擬成功跟失敗的兩種情境，讓我們在不依賴後端的狀況下完成一個非常基礎的購物車前端實現。

最近完成公司的 AI 培訓後，開始思考我們說的模型（Model）跟軟體開發中的領域模型（Domain Model）是否有關聯，如果仔細思考，似乎在抽象層面上是類似的。

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

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

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

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

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

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

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