「喵」 — 淺談 Over Specification

有在寫單元測試的人都知道，單元測試最好的驗證方式就是驗回傳，其次是驗狀態，最該避免旳是驗互動。

今天我們要從另一個面向來討論：Over Specification。當然，這裡談的是 Unit Test 的 Over Specification。

什麼是 Over Specification？我們來看看字典怎麼定義的：

source: Wikitionary

簡單來說，就是在指定（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