iT邦幫忙

2021 iThome 鐵人賽

DAY 1
3
Software Development

你就是都不寫測試才會沒時間:Kuma 的 30 天 Unit Test 手把手教學,從理論到實戰 (Java 篇)系列 第 1

Day 01 「科學 v.s. 數學」前言

筆者從業數年,面試過不少程式開發者。每當問到對方是否有做單元測試時,絕大多數的面試者總會說:
「我知道測試很重要,但我們沒時間寫測試。」
「我知道測試可以避免不必要的錯誤,但我們沒時間寫測試。」
「我知道測試可以加速開發,但我們沒時間寫測試。」

羅蘭夫人
羅蘭夫人,圖片截自網路

『沒時間啊,沒時間,天下古今幾多之罪惡假汝之名而行!』

你都不測,你怎麼知道你做的功能是對的?你怎麼知道你的新修改沒有把舊功能搞壞?你怎麼好意思告訴老闆你「做完」了?

「我們有 QA 呀!」

我們來看看一間公司,如果 RD 只開發,QA 只測試,會發生什麼事情?QA説,我的工作就是抓 bug,我要盡可能地多抓 bug,這樣才能顯示我的工作能力好。所以 bug 越多越好。

RD 呢?RD 説,我的工作就是寫程式,所以我收到需求就「熱熱寫,快快送」,頂多自己手動稍微測一下,反正 QA 會細測,有錯他會跟我說。我所有的工作要盡可能地快速經手,這樣才能顯示我的工作能力好。雖然這樣 bug 會變多,但我無妨,那不是我的 KPI。

有發現嗎?一間公司,如果 RD 只開發,QA 只測試,造成的後果就是「沒有人有動機去避免 bug 產生」,接著就是品質無法得到保證。

品質不是選項

軟體管理常見的取捨,都是在「時間」、「成本」、「品質」當中挑選兩項,並且時常把「你只能滿足其中兩項」掛在嘴邊。然而,事實真的是這樣嗎?在我看來,「品質」不應該是選項,因為品質一旦犧牲了,你會直接失去消費者的信任,這下你時間再快,成本再低都沒用。

軟體管理
軟體管理三元素,圖片截自網路

真要我說,你應該要首先先讓品質維持在一定程度以上,然後再視情況在另外兩個因素中選一個才對。為什麼不說品質要高,而是「一定程度以上」呢?你知道的,哪有人寫程式沒 bug 的?只是多或少,好不好抓,及抓到好不好修的差別而已。這,就是測試可以發揮的地方了!

是科學還是數學?

很多人都說電腦科學是數學,但也有很多人不這麼想。數學跟科學都追求正確,但方法不同。數學要求你「證明」,透過一些邏輯的交錯應用,來證明一件事 100% 是對的,無論日換星移,這件事都不會變。但科學不同,科學追求正確的方法是「實驗」。科學家先針對一個現象提出一個假說,經過巧妙的安排,試圖重現這個現象。幾十年幾百年過去,無數次的實驗結果,都沒人推翻這個假說,那我們就相信這個假說是正確的。

對此,Uncle Bob 曾說:「電腦科學是科學,不是數學。給你一段程式碼,要你證明他的正確性成本太高了,幾乎辦不到,但你可以做實驗驗證他,並且無數次不斷重複這個實驗,當你實驗次數夠多,大家就相信這段程式碼是對的了。」

這裡的實驗,就是「測試」。

這就是我們為什麼要測試。我們給出一段程式,我告訴老闆它是對的,老闆憑什麼相信你說他是對的?因為 CI/CD 工具的儀表板上明明白白顯示出,過去這段程式碼跑過無數次測試,從來沒有出錯過,因此他應該要相信這段程式碼是對的。

測試要自動化

測試有分很多種,而一切軟體工程的根源,就是最基礎也最單純的「單元測試」了。Martin Fowler 曾經拿單元測試與整合測試比較,並給出他認為的定義:「能夠獨立於所有其他服務或元件而獨立運行的測試,就是單元測試,而不管是不是有使用 mock 或 stub 技術...單元測試關注『我們的功能跑起來情況如何』,而整合測試關注『我們的功能與其他元件合作跑起來情況如何』。」

如此一來單元測試定義就簡單多了:「驗證我手上敲的程式的表現跟我腦中想像的是否一致」。

如果寫程式的人都能夠附上能佐證正確性的單元測試,那麼確保功能性就簡單多了,因為現代的 CI/CD 工具太厲害了,可以隨時隨地觸發,你甚至不用盯著螢幕看,結果出來他會自動通知你。事到如今,能阻礙你寫測試的只剩下「你寫得多快」了。至於要怎麼快,那就要看你做得多好了。對此,Uncle Bob 都說了:「你唯一能把事情做快的方法,就是把它做好。」

內容列表

本系列文章圍繞著單元測試,將會包含以下軟體工程概念:

  • 單元測試的基本概念
  • 單元測試與依賴
  • 單元測試的進階應用
  • 單元測試與重構
  • 單元測試驅動開發 (TDD)
  • 單元測試與 Clean Architecture
  • 單元測試與流程管理

讀者從上述列表中不難看出,大家平常常聽到的諸多軟體工程實踐,大多都與單元測試有關。應該說,他們大部分都必須建立在單元測試之上,才能有比較好的發揮。

本系列文章中,需要時都會有程式碼輔助理解。讀者可以直接下載下來閱讀原始碼,或是參考著練習。搭配文章一起服用,可達到理論與實踐並重的成效。作者期待的效果是,讀者未來在掌握訣竅後,在工作上真正能靠它來「加速」,如此一來,想要寫測試,就不用非得老闆多給時間不可了。

謎之聲:「那我們就開始吧!」

Reference

  1. 範例程式碼下載點:https://github.com/bearhsu2/ithelp2021.git

下一篇
Day 02 「住手!你想搞死 QA 嗎?」 單元測試是測試還是功能?
系列文
你就是都不寫測試才會沒時間:Kuma 的 30 天 Unit Test 手把手教學,從理論到實戰 (Java 篇)30

1 則留言

0
ytyubox
iT邦新手 5 級 ‧ 2021-12-27 10:47:31

好文,測試真的是加速,如果我是老闆發現測試的好還不用爆!

我要留言

立即登入留言