優雅的 RSpec 測試 - 測試替身
測試替身(Test Double)是在撰寫單元測試中經常會使用到的一項技巧,我們可以透過替換某個物件的特定行為或者製作替身來達到驗證某個行為的效果,然而如果濫用測試替身的話,則很容易無法正確的驗證物件行為。
測試替身(Test Double)是在撰寫單元測試中經常會使用到的一項技巧,我們可以透過替換某個物件的特定行為或者製作替身來達到驗證某個行為的效果,然而如果濫用測試替身的話,則很容易無法正確的驗證物件行為。
除了共用案例和自訂匹配器之外,我們可以像 Rails 的 View Helper 一樣定義輔助方法,假設我們的測試需要做非常多的準備,利用自訂輔助方法可以幫我們極大的改善測試案例的可讀性。
我們已經知道在 RSpec 中有強大的匹配器可以使用,除此之外也可以將經常重複的測試案例設計成共用案例來使用,那麼自訂匹配器則是用來針對我們系統中物件常見的回傳來處理。
在我們在撰寫測試的過程中,可能因為同一類型的物件行為有著類似的情況,因此會需要重複的專寫相似的測試案例,這個時候我們就可以利用「共用案例(Shared Example)」的機制來重複利用這些測試案例。
前面兩篇文章已經將比較常會被使用的匹配器介紹完畢,接下來我們要再介紹「錯誤」跟「滿足」兩種匹配器,這些匹配器的使用就可以對應大多數的情況。除此之外,RSpec 還提供非常豐富的匹配器可以使用,在撰寫斷言之前可以先去查詢適合的匹配器。
我們了解了常見的匹配方式之後,接下來我們要進一步善用這些匹配器來做到更加優雅的比對,讓我們的測試看起來更容易閱讀。
經過測試案例、組織測試、前置處理等等概念後,我們現在已經掌握了對於如何規劃一個「容易理解」的測試有所概念,接下來我們要針對 RSpec 的斷言機制中,強大的「匹配器(Matcher)」來深入討論。
在上一個段落中,我們有提到需要限制 Let 的使用,然而當我們有比較複雜的測試前置條件時,就很難避免撰寫過於複雜的測試主題,此時就可以利用「前置處理」的機制來解決這個問題。
了解如何撰寫基本的測試後,我們需要學習如何組織一個測試。在進行單元測試的時候,我們不太可能單純針對一個方法測試,而是會針對整個物件進行驗證,因此需要區分不同情境、測試目標。
在我的經驗中,要將測試寫好並不是一件容易的事情。很多時候,我們會看到不少「測試」是難以閱讀的,這也讓我們很難了解到測試的意圖,因此我們要先針對「結構」進行一些討論。