Global Game Jam 2024 - 軟體架構適用遊戲開發嗎?
答案是肯定的,遊戲也是軟體的一種,善用軟體架構相關的思考對於設計遊戲仍然非常有幫助。今年的 Global Game Jam 因為隊友都比較熟悉 Unity,因此我也挑戰在 Unity 實踐去年沒有完善的部分。
答案是肯定的,遊戲也是軟體的一種,善用軟體架構相關的思考對於設計遊戲仍然非常有幫助。今年的 Global Game Jam 因為隊友都比較熟悉 Unity,因此我也挑戰在 Unity 實踐去年沒有完善的部分。
使用 Cucumber 的 Gherkin 來撰寫測試是相當直覺的,然而這需要我們付出一些代價去實現「步驟定義」來將文件跟測試整合起來,然而這也是一個很好的機會讓我們去反思如何操作我們的軟體。
對功能描述之後,我們需要將詳細的步驟寫下來,讓 Cucumber 知道該怎麼做來檢查這個功能是否符合預期,因此我們可以使用 Given、When、Then 來進行描述。
Cucumber 的測試撰寫基本上是非常容易的,因為我們不是去配合程式來實現測試,而是直接去撰寫測試後,讓程式去配合測試。
在實際了解 Cucumber 的應用方式之前,我一直認為使用 Cucumber 撰寫測試是一件非常麻煩的事情,因為我們會需要實作許多 Step Definition(步驟定義)來讓文件中的某個行為可以被使用。
然而,當我了解到 Cucumber 的價值之後,就變成我優先選用的工具。
我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription
的例外,然而這種情況是無法在驗收測試的狀況下被重現出來,因為使用者無法在正常狀況做到這件事情,在這種狀況下單元測試就非常適合。
因為我們還沒有完善所有的邏輯,因此儲存到資料庫將狀態持久化的機制可以先不處理,接下來我們需要建構不同的「測試資料」讓訂閱狀態有不同的呈現,而不是像現在這樣只有寫死的訊息。
過去我在寫測試的時候經常會有「這裡該測試嗎?」的疑問,然而這個問題其實可以從另一個角度思考,那就是「這些測試組以完善規則嗎?」去想,以我們第一個 E2E Testing 的測試作為例子,雖然可以通過測試,然而實作的內容只是一些假資料,我們需要用另一條測試從其他角度去驗證,讓實作最終變成我們預期的樣子。
通過規格的分析我們準備好了 E2E Testing 的文件,以及對應的步驟實現,然而在這個狀態下是無法順利通過測試的,因此我們需要進行一些實作。在只有一條測試的狀況下,我們可以用非常簡單的方法通過這個測試。
當我們有了關鍵案例(Key Examples)後,規格已經相對的明確,如果還能夠被自動化測試的話,是不是一件更好的事情呢?我們可以利用 Cucumber 來實踐 E2E Testing(端對端測試)讓我們模擬使用者實際操作來驗證規格的完善。