關於 #測試 的內容

過去我在寫測試的時候經常會有「這裡該測試嗎？」的疑問，然而這個問題其實可以從另一個角度思考，那就是「這些測試組以完善規則嗎？」去想，以我們第一個 E2E Testing 的測試作為例子，雖然可以通過測試，然而實作的內容只是一些假資料，我們需要用另一條測試從其他角度去驗證，讓實作最終變成我們預期的樣子。

通過規格的分析我們準備好了 E2E Testing 的文件，以及對應的步驟實現，然而在這個狀態下是無法順利通過測試的，因此我們需要進行一些實作。在只有一條測試的狀況下，我們可以用非常簡單的方法通過這個測試。

當我們有了關鍵案例（Key Examples）後，規格已經相對的明確，如果還能夠被自動化測試的話，是不是一件更好的事情呢？我們可以利用 Cucumber 來實踐 E2E Testing（端對端測試）讓我們模擬使用者實際操作來驗證規格的完善。

經過接近半年的連載，最後我們要來聊一下如何「加入測試」的問題，雖然我們了解到了各種撰寫測試的技巧，但往往我們是卡在不知道從何開始測試，因此跟大家分享一些實用的小技巧。

雖然我們沒有使用依賴注入的技巧，或者實作中有耦合的問題存在，在 Ruby 中因為語言特性的關係，我們還是有非常多方式可以進行測試，然而這也會讓我們的測試變得複雜。

在這系列的文章中，我們已經對使用 RSpec 進行測試的技巧有一定的理解，接下來我們來討論一下「可測試性」這件事情。

最近在準備明年（2024）的連載主題，在實作的時候意外發現自己逐漸習慣「不使用瀏覽器」的狀況下去進行開發，除了比較常用的後端情境之外，連前端也很順利的可以實踐這件事情。

在撰寫 RSpec 的過程中，我們大多會使用 expect（預期）搭配 receive （接收）來驗證某個方法有被呼叫，然而這會讓我們需要將「預期」寫在實際的行為之前，在驗證的邏輯上似乎有點奇怪，因此我們可以用 Spy 功能替代，在呼叫實際的方法後再去驗證行為。

我們已經瞭解到該如何利用 Allow 來改變一個物件的回傳，然而在我們使用 Allow 的時候還可能會遇到需要呼叫多次、搭配 Block 使用的情況，在這樣的狀況下該如何處理呢？

在 RSpec 的測試中，我們最常會使用到的是 Allow 來改變一個物件的回傳，基本上在需要使用測試替身（Test Double）的地方，就會使用用到。