source: etsy.com

「信心、信任」 — 談單元測試的「單元」

--

前陣子收到一位讀者的來信,他針對我的書「你就是不寫測試才會沒時間」的內容,問了我一些延伸的問題。

我覺得這些問題應該是大部份要在工作上開始加入單元測試的人都多多少少會遇到的,所以直接寫成文章,直接回應該讀者的同時,也讓部落格的其他讀者,如有類似問題的,也能一起得到解答。

此為第一題:

這個問題不難回答,但前提是我們得先考慮「單元測試」到底要測什麼。

一般來說,單元測試屬於「支持團隊」、「面向技術」的功能測試。它測的是「我手打出來的 code,其表現有沒有和我腦中理解的一樣」。那我腦中的理解從哪來?要嘛是 Spec,要嘛是 PO 或老闆,對吧?所以,我用我的理解寫一次 code,再寫一次 test,兩個一起跑,會過,我就有信心這兩件事是一致了。

再往下探討,Spec 寫的是用戶感受得到的行為,還是類別的 input-output 定義?一般來說是前者吧?(如果是後者你就要考慮一下你是否還要繼續這份工作了)既然如此,那一個 class 的行為長什樣子重要嗎?很顯然的不重要了對吧?

從單元測試的另一個角度來看,測試應該要能「幫助重構」才對。程式的行為是「功能需求」,而分層與類別設計是「非功能需求」。如果你今天每個類都一定要有自己的測試,那你隨便改一下設計,測試就會壞光光,但明明你的功能沒有動,而且測試應該要證明這件事呀!此時,很遺憾地,你的「分層與類別設計」就被你的測試「綁架」了,就起不了「幫助重構」的作用了。

話已至此,我想這一題的答案就呼之欲出了。一個功能與其測試完成後,對設計所做的優化不該大量地破壞測試,因此,只要原功能的保護力是足夠的,我們理當不需要為新抽出來的 function 或 class 做單獨測試才是。

除非,晚點我們又為這個新 function 或 class 加上了新功能,那就另當別論了…

Reference

More about Me

--

--