![蒼時弦也](/images/avatar_huf49a82458f53859c626adf20da3bee9f_18804_64x64_resize_q90_h2_box_3.webp)
優雅的 RSpec 測試 - 共用案例
在我們在撰寫測試的過程中,可能因為同一類型的物件行為有著類似的情況,因此會需要重複的專寫相似的測試案例,這個時候我們就可以利用「共用案例(Shared Example)」的機制來重複利用這些測試案例。
在我們在撰寫測試的過程中,可能因為同一類型的物件行為有著類似的情況,因此會需要重複的專寫相似的測試案例,這個時候我們就可以利用「共用案例(Shared Example)」的機制來重複利用這些測試案例。
因為已經非常習慣寫軟體測試在用工程師的方式入門生成式 AI - Stable Diffusion 這篇文章實作的過程中,我開始思考「Generative AI 的產出能被測試嗎?」這樣的問題。
前面兩篇文章已經將比較常會被使用的匹配器介紹完畢,接下來我們要再介紹「錯誤」跟「滿足」兩種匹配器,這些匹配器的使用就可以對應大多數的情況。除此之外,RSpec 還提供非常豐富的匹配器可以使用,在撰寫斷言之前可以先去查詢適合的匹配器。
上週(2023/02/22)可能是看了不少 AI 應用的發展,覺得該趕緊補上進度,以免在未來來不及掌握這樣的工具。不過,如果只是串接 ChatGPT 的 API 或者拿 Stable Diffusion WebUI 來產生圖,似乎不是工程師也能做到,作為工程師能做些什麼嗎?
我們了解了常見的匹配方式之後,接下來我們要進一步善用這些匹配器來做到更加優雅的比對,讓我們的測試看起來更容易閱讀。
最近要實作一個功能,大致上是搜尋一群使用者符合條件的資料,然後回傳這筆資料下的另一個符合條件的資料,如果使用一般的方式來做,會需要分開撰寫查詢,並且多次的查詢,然而我們可以利用 Ruby 的語言特性來簡化這段程式。
經過測試案例、組織測試、前置處理等等概念後,我們現在已經掌握了對於如何規劃一個「容易理解」的測試有所概念,接下來我們要針對 RSpec 的斷言機制中,強大的「匹配器(Matcher)」來深入討論。
在上一個段落中,我們有提到需要限制 Let 的使用,然而當我們有比較複雜的測試前置條件時,就很難避免撰寫過於複雜的測試主題,此時就可以利用「前置處理」的機制來解決這個問題。
在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情,雖然有很多人嘗試,但我們仍沒有找到一個很好的方法解決。
同時,寫測試對許多人來說是一種拖慢開發速度的工作,這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發,運用這段時間學到的 Domain-Driven Design(領域驅動設計)、Clean Architecture(清楚架構)、敏捷開發、ATDD(驗收測試驅動開發)等技巧來做實驗。
了解如何撰寫基本的測試後,我們需要學習如何組織一個測試。在進行單元測試的時候,我們不太可能單純針對一個方法測試,而是會針對整個物件進行驗證,因此需要區分不同情境、測試目標。