之前因為使用 Playwright 的方式造假後端 API 造成前端的實際畫面是無法使用，接下來在後端的部分我們要將商品 API 完成一個雛形讓前端可以恢復正常。

在實際的開發流程中，前後端確認完畢 API 的資料結構後會同步進行，我們切分成兩個段落因此看起來是依序處理。

前端的實作目前告一段落，我們將關注放到後端的部分。這次會直接使用 Grape 這個 Gem 來直接搭建 API 伺服器而不使用 Rails，並且刻意使用 Cucumber 來撰寫測試，在正常的狀況下只需要使用跟前端同一份即可，這次主要是展示針對後端可以怎樣實現。

在開始實作後端之前，我們先將原本都集中在 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）之外，我們還可以加入輔助方法、標籤等等設定，讓我們的測試案例更加容易維護。