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

有段時間沒有寫 Domain-Driven Design（以下簡稱 DDD）的主題，最近剛好跟一些朋友討論以及做了不少實驗，覺得可以針對這些題目再一次討論在 Ruby on Rails 中導入會遇到的問題。

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

約兩個月前，我寫了2023 年成為外商裁員的天選之人該做些什麼？這篇文章告訴大家參與 2023 年最流行的裁員活動，經過一個月多的面試，順利開始了新的工作。

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

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

之前寫過# 從 ChatGPT 看學習與對工程師的影響， 這篇文章原本想試著讓 ChatGPT 幫忙，給了兩篇自己的文章作為範例，再給出我規劃的文章架構，得到了一篇看起來有內容實際上什麼都沒說的文章，於是這篇文章還是得自己處理，這大概就是目前 ChatGPT 的極限吧！

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

因為已經非常習慣寫軟體測試在用工程師的方式入門生成式 AI - Stable Diffusion 這篇文章實作的過程中，我開始思考「Generative AI 的產出能被測試嗎？」這樣的問題。

前面兩篇文章已經將比較常會被使用的匹配器介紹完畢，接下來我們要再介紹「錯誤」跟「滿足」兩種匹配器，這些匹配器的使用就可以對應大多數的情況。除此之外，RSpec 還提供非常豐富的匹配器可以使用，在撰寫斷言之前可以先去查詢適合的匹配器。