關於 #測試 的內容

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

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

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

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

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

在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情，雖然有很多人嘗試，但我們仍沒有找到一個很好的方法解決。

同時，寫測試對許多人來說是一種拖慢開發速度的工作，這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發，運用這段時間學到的 Domain-Driven Design（領域驅動設計）、Clean Architecture（清楚架構）、敏捷開發、ATDD（驗收測試驅動開發）等技巧來做實驗。

• 遊戲：https://ggj2023.aotoki.cloud/（可能要等一下）
• 原始碼：https://github.com/elct9620/GlobalGameJam2023

了解如何撰寫基本的測試後，我們需要學習如何組織一個測試。在進行單元測試的時候，我們不太可能單純針對一個方法測試，而是會針對整個物件進行驗證，因此需要區分不同情境、測試目標。

在我的經驗中，要將測試寫好並不是一件容易的事情。很多時候，我們會看到不少「測試」是難以閱讀的，這也讓我們很難了解到測試的意圖，因此我們要先針對「結構」進行一些討論。

因為在 2023 年初就成為天選之人（2023 年成為外商裁員的天選之人該做些什麼？）而開始找工作，運氣很不錯的在獵頭協助跟朋友的內推，我在 1/18 跟 1/19 分別收到兩間公司的作業，但是我不想留到農曆年後才處理，因此決定用空檔趕在連假前完成他們！

幾乎所有的 Ruby 開發者都聽過 RSpec 然而 Rails 和 Ruby 都是使用名為 Minitest 的測試框架進行測試的，那麼 RSpec 做了什麼事情，讓更多開發者比起使用 Minitest 更喜歡使用 RSpec 呢？