
預期外狀況的測試 - Rails 開發實踐
我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription
的例外,然而這種情況是無法在驗收測試的狀況下被重現出來,因為使用者無法在正常狀況做到這件事情,在這種狀況下單元測試就非常適合。
我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription
的例外,然而這種情況是無法在驗收測試的狀況下被重現出來,因為使用者無法在正常狀況做到這件事情,在這種狀況下單元測試就非常適合。
因為我們還沒有完善所有的邏輯,因此儲存到資料庫將狀態持久化的機制可以先不處理,接下來我們需要建構不同的「測試資料」讓訂閱狀態有不同的呈現,而不是像現在這樣只有寫死的訊息。
過去我在寫測試的時候經常會有「這裡該測試嗎?」的疑問,然而這個問題其實可以從另一個角度思考,那就是「這些測試組以完善規則嗎?」去想,以我們第一個 E2E Testing 的測試作為例子,雖然可以通過測試,然而實作的內容只是一些假資料,我們需要用另一條測試從其他角度去驗證,讓實作最終變成我們預期的樣子。
通過規格的分析我們準備好了 E2E Testing 的文件,以及對應的步驟實現,然而在這個狀態下是無法順利通過測試的,因此我們需要進行一些實作。在只有一條測試的狀況下,我們可以用非常簡單的方法通過這個測試。
當我們有了關鍵案例(Key Examples)後,規格已經相對的明確,如果還能夠被自動化測試的話,是不是一件更好的事情呢?我們可以利用 Cucumber 來實踐 E2E Testing(端對端測試)讓我們模擬使用者實際操作來驗證規格的完善。
經過接近半年的連載,最後我們要來聊一下如何「加入測試」的問題,雖然我們了解到了各種撰寫測試的技巧,但往往我們是卡在不知道從何開始測試,因此跟大家分享一些實用的小技巧。
雖然我們沒有使用依賴注入的技巧,或者實作中有耦合的問題存在,在 Ruby 中因為語言特性的關係,我們還是有非常多方式可以進行測試,然而這也會讓我們的測試變得複雜。
在這系列的文章中,我們已經對使用 RSpec 進行測試的技巧有一定的理解,接下來我們來討論一下「可測試性」這件事情。
最近在準備明年(2024)的連載主題,在實作的時候意外發現自己逐漸習慣「不使用瀏覽器」的狀況下去進行開發,除了比較常用的後端情境之外,連前端也很順利的可以實踐這件事情。
在撰寫 RSpec 的過程中,我們大多會使用 expect
(預期)搭配 receive
(接收)來驗證某個方法有被呼叫,然而這會讓我們需要將「預期」寫在實際的行為之前,在驗證的邏輯上似乎有點奇怪,因此我們可以用 Spy 功能替代,在呼叫實際的方法後再去驗證行為。