
優雅的 RSpec 測試 - 常見匹配器
經過測試案例、組織測試、前置處理等等概念後,我們現在已經掌握了對於如何規劃一個「容易理解」的測試有所概念,接下來我們要針對 RSpec 的斷言機制中,強大的「匹配器(Matcher)」來深入討論。
經過測試案例、組織測試、前置處理等等概念後,我們現在已經掌握了對於如何規劃一個「容易理解」的測試有所概念,接下來我們要針對 RSpec 的斷言機制中,強大的「匹配器(Matcher)」來深入討論。
在上一個段落中,我們有提到需要限制 Let 的使用,然而當我們有比較複雜的測試前置條件時,就很難避免撰寫過於複雜的測試主題,此時就可以利用「前置處理」的機制來解決這個問題。
在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情,雖然有很多人嘗試,但我們仍沒有找到一個很好的方法解決。
同時,寫測試對許多人來說是一種拖慢開發速度的工作,這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發,運用這段時間學到的 Domain-Driven Design(領域驅動設計)、Clean Architecture(清楚架構)、敏捷開發、ATDD(驗收測試驅動開發)等技巧來做實驗。
了解如何撰寫基本的測試後,我們需要學習如何組織一個測試。在進行單元測試的時候,我們不太可能單純針對一個方法測試,而是會針對整個物件進行驗證,因此需要區分不同情境、測試目標。
在我的經驗中,要將測試寫好並不是一件容易的事情。很多時候,我們會看到不少「測試」是難以閱讀的,這也讓我們很難了解到測試的意圖,因此我們要先針對「結構」進行一些討論。
因為在 2023 年初就成為天選之人(2023 年成為外商裁員的天選之人該做些什麼?)而開始找工作,運氣很不錯的在獵頭協助跟朋友的內推,我在 1/18 跟 1/19 分別收到兩間公司的作業,但是我不想留到農曆年後才處理,因此決定用空檔趕在連假前完成他們!
幾乎所有的 Ruby 開發者都聽過 RSpec 然而 Rails 和 Ruby 都是使用名為 Minitest 的測試框架進行測試的,那麼 RSpec 做了什麼事情,讓更多開發者比起使用 Minitest 更喜歡使用 RSpec 呢?
撰寫測試的方式有很多種,如何為軟體加入測試也是一門深奧的學問。我個人是比較推薦使用 A-TDD(Acceptance Test Driven Development,驗收測試驅動開發)跟 TDD(Test Driven Development,測試驅動開發)兩種方式來進行開發。
測試幾乎是現代軟體開發的必備技能,然而我們對於測試的理解、撰寫、使用的熟練程度,會極大的影響我們的軟體是否穩定,也因此具備一個優質的測試技能對於軟體的品質與改善都會有非常大的影響。
前幾天在 Facebook 社團 Ruby on Rails 新手村看到有人提問關於 Mock 和 Stub 的問題,其實問題本身很簡單,不過也讓我發現雖然我們都知道該寫「測試」但很多時候是不清楚怎麼撰寫的,這篇文章會先來分享一下我對 Mock 的看法,更詳細的 RSpec 測試系列請期待明年的「優雅的 RSpec 測試」連載。