優雅的 RSpec 測試 - 組織測試
了解如何撰寫基本的測試後,我們需要學習如何組織一個測試。在進行單元測試的時候,我們不太可能單純針對一個方法測試,而是會針對整個物件進行驗證,因此需要區分不同情境、測試目標。
了解如何撰寫基本的測試後,我們需要學習如何組織一個測試。在進行單元測試的時候,我們不太可能單純針對一個方法測試,而是會針對整個物件進行驗證,因此需要區分不同情境、測試目標。
在我的經驗中,要將測試寫好並不是一件容易的事情。很多時候,我們會看到不少「測試」是難以閱讀的,這也讓我們很難了解到測試的意圖,因此我們要先針對「結構」進行一些討論。
因為在 2023 年初就成為天選之人(2023 年成為外商裁員的天選之人該做些什麼?)而開始找工作,運氣很不錯的在獵頭協助跟朋友的內推,我在 1/18 跟 1/19 分別收到兩間公司的作業,但是我不想留到農曆年後才處理,因此決定用空檔趕在連假前完成他們!
幾乎所有的 Ruby 開發者都聽過 RSpec 然而 Rails 和 Ruby 都是使用名為 Minitest 的測試框架進行測試的,那麼 RSpec 做了什麼事情,讓更多開發者比起使用 Minitest 更喜歡使用 RSpec 呢?
上週五吃個午飯回到電腦前,發現電腦被遠端鎖定,嘗試了幾次後在個人信箱中收到了裁員的訊息,才發現自己成為天選之人。然而並沒有太驚訝,畢竟這幾個月軟體業的新聞,不少外商都在裁員。
撰寫測試的方式有很多種,如何為軟體加入測試也是一門深奧的學問。我個人是比較推薦使用 A-TDD(Acceptance Test Driven Development,驗收測試驅動開發)跟 TDD(Test Driven Development,測試驅動開發)兩種方式來進行開發。
大多數使用過 Ruby 的工程師都知道 Ruby 有一個特別的語言特性叫做 Mixin(混合)可以透過定義一個 Module(模組)然後被其他類別引用,如果從 DCI(Data Context Interaction)的角度來看,其實是一種脈絡的表現。
測試幾乎是現代軟體開發的必備技能,然而我們對於測試的理解、撰寫、使用的熟練程度,會極大的影響我們的軟體是否穩定,也因此具備一個優質的測試技能對於軟體的品質與改善都會有非常大的影響。
最近在實作一個會員集點功能的時候意外發現很適合作為「領域事件(Domain Event)」的例子,在很多情況下其實不容易去描述這個概念,然而這個例子倒是很好的反應這個概念,以及 Rails 的特性所產生的變化。
對脈絡(Context)比較有清晰的概念是在今年研究 Domain-Driven Design 的時候,這幾天剛好因為工作需要修正 Golang 的靜態分析警告,想到這其實也跟脈絡有些關係,因此這篇文章會來跟大家分享幾種常見的「程式脈絡」