關於 #測試 的內容

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

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

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

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

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

在測試中，我們經常會看到 Mock 和 Stub 這兩個詞，很多時候也不容易區分清楚。在 RSpec 中我們基本上不會看到 Mock 或者 Stub 這兩個詞，取而代之的是 Double 和 Allow。

測試替身（Test Double）是在撰寫單元測試中經常會使用到的一項技巧，我們可以透過替換某個物件的特定行為或者製作替身來達到驗證某個行為的效果，然而如果濫用測試替身的話，則很容易無法正確的驗證物件行為。

除了共用案例和自訂匹配器之外，我們可以像 Rails 的 View Helper 一樣定義輔助方法，假設我們的測試需要做非常多的準備，利用自訂輔助方法可以幫我們極大的改善測試案例的可讀性。

我們已經知道在 RSpec 中有強大的匹配器可以使用，除此之外也可以將經常重複的測試案例設計成共用案例來使用，那麼自訂匹配器則是用來針對我們系統中物件常見的回傳來處理。

在我們在撰寫測試的過程中，可能因為同一類型的物件行為有著類似的情況，因此會需要重複的專寫相似的測試案例，這個時候我們就可以利用「共用案例（Shared Example）」的機制來重複利用這些測試案例。