「喵」 — 淺談 Over Specification
有在寫單元測試的人都知道,單元測試最好的驗證方式就是驗回傳,其次是驗狀態,最該避免旳是驗互動。
今天我們要從另一個面向來討論:Over Specification。當然,這裡談的是 Unit Test 的 Over Specification。
什麼是 Over Specification?我們來看看字典怎麼定義的:
簡單來說,就是在指定(Specify)的過程中,曝露過多重複而不必要的細節。這樣的行為,在單元測試中是不建議的。
筆者工作中當見的 Over Specification 有幾種:
驗兩種型態
首先是「又驗回傳又驗狀態」。舉例,當你今天要做一個公司用的電話轉接系統,你的「問候語」肯定在上班時間與下班時間要不同吧?於是為了測試功能有沒有寫對,你可能就先調成上班,再取問候語 API 的回傳值來驗證。這沒問題,但你可能會想:「這時系統已經變成上班狀態了,我應該也要確定這件事才對。」
當你這麼想,你已經在過度指定了。事實上,系統既然能回傳正確問候語,用戶感受得到的功能就是對的。這時系統是什麼狀態,根本就不重要。
驗完整內文
其次是計對回傳值,做過多、過於細節的檢驗。舉例,我們的上班時間的問候語是:「Hi!用戶 Jay Chow,請撥分機號碼,或撥 9,由總機為您服務。」
此時如果你就把上面整句拿來 assert 回傳值,當然是會對,但這時你就又遇上 Over Specification 的問題了。
為什麼?因為容易壞。一整句句子中,不是每個部份重要度都一樣。在上句中,用戶 Jay Chow 、分機號 9,這兩個訊息很明顯地比起其他部份重要許多,例如那個驚嘆號。一旦你就這麼測下去,哪天 PM 覺得驚嘆號太強烈想換掉,你的測試就會壞了。
但,你的功能真的壞了嗎?
單元測試是功能測試
是的:
單元測試是妥妥的功能測試。
上面的「驚嘆號太強烈」與「系統狀態的設計」,都是非功能需求,不管你是因為要測非功能需求開一個接口給功能測試用,還是因為非功能需求而使功能測試壞掉,這都不是好事。
因此,不過度指定,不是單純的時間考量,而是經過評估,為了測試的穩健度與其警示的可信度,而做出的決定。
Reference
- https://en.wiktionary.org/wiki/overspecify
- https://dev.to/edgaremmanuel/writing-maintainable-tests-overspecification-in-unit-tests-2lak
More about Me
- 更多軟體工程相關討論:https://www.facebook.com/kukumamaya
- 我的YouTube 頻道:https://www.youtube.com/@yu-songsyu6598
- 沒時間寫測試?沒時間重構?你就是不寫測試才會沒時間: https://www.tenlong.com.tw/products/9786263332645?list_name=lv