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

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

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

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

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

上週（2023/02/22）可能是看了不少 AI 應用的發展，覺得該趕緊補上進度，以免在未來來不及掌握這樣的工具。不過，如果只是串接 ChatGPT 的 API 或者拿 Stable Diffusion WebUI 來產生圖，似乎不是工程師也能做到，作為工程師能做些什麼嗎？

我們了解了常見的匹配方式之後，接下來我們要進一步善用這些匹配器來做到更加優雅的比對，讓我們的測試看起來更容易閱讀。

最近要實作一個功能，大致上是搜尋一群使用者符合條件的資料，然後回傳這筆資料下的另一個符合條件的資料，如果使用一般的方式來做，會需要分開撰寫查詢，並且多次的查詢，然而我們可以利用 Ruby 的語言特性來簡化這段程式。

經過測試案例、組織測試、前置處理等等概念後，我們現在已經掌握了對於如何規劃一個「容易理解」的測試有所概念，接下來我們要針對 RSpec 的斷言機制中，強大的「匹配器（Matcher）」來深入討論。

在上一個段落中，我們有提到需要限制 Let 的使用，然而當我們有比較複雜的測試前置條件時，就很難避免撰寫過於複雜的測試主題，此時就可以利用「前置處理」的機制來解決這個問題。