iT邦幫忙

2021 iThome 鐵人賽

DAY 18
3
Software Development

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

Day 18 「春暖鴨先知」TDD 來了

古語有云:「竹外桃花三兩枝,春江水暖鴨先知。」春天不會早上起來敲你家門,跟你說他來了。冬天進入春天的過程,是一天一天變化的。等你發現春天來臨時,外頭早已開遍桃花了。

我們寫程式時,結構在變「硬」有時快有時慢,但不論快慢,都不會「通知」你,都是你有一天要改一個小小功能,卻發現竟然要做非常大幅度的修改,這時才赫然驚覺:「糟了,是世界奇觀!不小心把軟體寫成硬體了!」


糟了,是世界奇觀!圖片截自臉書:高雄好過日

那怎麼辦?

今天起的連續三天,我們要聊的是這幾年大大改變筆者本身寫程式習慣的開發方法:Test Driven Development,江湖人稱 TDD。

起源

TDD 的發明,一般認為是 Kent Beck 在 2,000 年左右提出的,但其實 Kent Beck 自己後來也說,他不是創始者,他只是把一個已經有人在用,而他覺得很棒的開發方法系統化地整理出來,讓大家更容易使用而已。不論如何,這個方法在那之後至今 20 多年來,確實改變很多人的 coding 習慣,包含他的好友,人稱 Uncle Bob 的 Robert C. Martin。

Uncle Bob 曾不只一次在公開場合聊到他第一次見識到 Kent Beck 用 TDD 的方式,以「數秒 commit 一次」的方式,慢慢完成一項工作,而且做完的同時,程式、測試、重構,三件事情是同時完成的。並且不斷描述當時他有多震驚與興奮!總之在那之後,Uncle Bob 就成為了 TDD 的愛好者與推廣者了。

近二十年後,我也是 XD

TDD 基本操作

TDD 主要是由三個動作組成的:

  1. 寫一個錯誤的測試
  2. 使測試通過
  3. 重構

把一個功能,拆解成多個小小的驗收條件,不斷重複以上三個動作,直到功能完成,就形成了 TDD 的基本套路。為什麼說是「套路」?因為這只是一般形式,要真正在工作中用得上,沒那麼容易。首先,每個循環要包含哪些內容,就是門學問了。這個我們下一篇會深入討論,這裡讀者先了解原則即可。

上面所謂的原則,就是「紅綠燈原則」與「Baby Step 原則」。


圖片截自 http://www.anecon.com/blog/tdd-baby-steps/

在第一步依需求寫出一個測試後,不囉嗦,直接跑下去。這時測試會過就有鬼了,我還沒寫程式哩!所以 fail 是正常現像,請安心服用。這時 IDE 一般會以紅色標示,所以我們稱之為「紅燈狀態」。

接下來要做的事,就是寫程式讓它通過。這時,我們要秉持 Baby Step 原則,「盡量少做一點事」,或是「少做一點設計」,只求「這個測項」能通過,其他可以先不管。這時再跑測試, IDE 會呈現綠色,進入「綠燈狀態」。

此時很多人會直接進入下一個測項,而 Kent Beck 則建議我們且慢,先找看看有沒有可以重構的地方。接著跑測試,因為是「重構」,根據 Martin Fowler 的建議,重構不應該改變物件對外表現,所以這時,測試應該維持綠燈,也就是全部通過才對。

請特別注意第三步的重構,很多人使用 TDD 會掛掉,就是掛在這裡。在操作 TDD 時,因為每一步都很小,所以我們都以為沒什麼好重構的。還記得前幾篇中的「發獎學金」的例子嗎?事實其實是,在加入新需求時,儘管需求看起來不大,但程式的「擴展」與「變醜」,是一下子的事。如果我們不經常地停下來看看程式的樣貌,一看到壞味道就重構掉,等程式多完成一兩個測項再回頭來重構,很可能已經變得太醜而無力回天了。

原理

說到底,為什麼 TDD 會被設計成這個樣子?因為它希望我們「隨時」保持程式的可運行性與整潔度,並且不要過度設計。而這些目的是怎麼達到的?筆者閱讀過一些書籍,加上自己一些經驗與心得後,整理如下:

回想第一步,先寫一個錯誤測試的原因其實有二。第一,我們想要先確保接下來要加的功能,在程式寫完後,能滿足需求,於是先用測試來描述它。一但測試通過,就能說明程式是滿足需求的。第二,我們必須確保測試此時是 fail 的,因為當我們還沒加程式,測試就通過了,這代表這個測試什麼也沒測到,屬於「無效測試」,應該立即刪除,否則會損害測試的整潔度。很多人 TDD 越做越慢,測試整潔太差也是主因之一。

第二步,我們應該做「只能再多通過這個新測試」的邏輯。為什麼?因為多做事會多花時間呀!在下一個測試還沒出生之前,任何「超前部署」都是多餘而不實際的。

很多人喜歡在一開始就花大把大把的時間想好了完整設計,但事實上經常會動手做到一半後又腦袋一拍:「啊!我想到一個更好的解法了!」這時想到的解法通常會比一開始的還好,因為你手上握有的證據變多了,你更能做出較適當的判斷。如果你一開始已經有了一個非常完整的設計,並且已經做了很多先期準備,那此時你要丟棄的內容會非常多,非常浪費。倒不如一開始不要想那麼多,大方向抓住就開工,還比較實際一點,也比較經濟。

筆者的父親多年經商,他經常告誡我們:「做出來的商品,最好是每一件都能賣出去,就能把效應拉到最大。」筆者雖然後後來沒有克紹箕裘,但父親的教誨還是有聽進去的。

第三步的重構,目的就在「及早發現,及早治療」。如同前文所述,更適當的設計總是「待會兒」才會出現。每當做完一點點事情,我們應該給自己一點點時間來做這樣的審視與思考。這個一點點時間不用太久,通常二三十秒,就能夠看出端倪。

如果此時發現更好的設計,就應該直接改掉,因為我們才剛剛寫完邏輯,對整體結構非常熟悉,而且還有測試保護,此時正是重構成更好設計的最佳時間。

如果這時不做,心想著等等把所有功能都做完再來重構,恐怕到時壞味道已經累積太多,改都改不動,無法重構,只能重寫了。如果不小心走到這一步,相信很多人就會選擇放棄,就這樣 commit 後上線了。等到一段時間需要回來改這一段程式時,就要花更多時間理解,更多時間修改,如果想重構,也就要花更多時間了。這些「更多時間」都是沒有必要的花費,其實。

Kuma 表示

如果各位讀者有一種概念,叫做「TDD 就是先寫 test 再寫 code」,那真的是有很大的誤會。筆者認為,TDD 名字中雖有一個 Test,但本質上不是 Test,而是需求。就像每個 RD 都會想要「先確認需求」一樣,TDD 希望我們做的事,是「先試著描述需求」。你必須得先能成功描述需求,讓別人看得懂,或至少讓 30 秒後的你自己看得懂,你待會才有憑據去說明你剛寫好的 code 是「對」還是「不對」。

至於為什麼非得用 Unit Test 來描述呢?為什麼不寫在紙上、Google Sheet 中,或是其他地方呢?筆者認為原因有二。其一,Unit Test的結構,為「準備、跑、對答案」,這正巧與需求描述的必須元素「前提、過程、結果」對應得上。其二,Unit Test 可以執行,而且「錯了會叫」。寫在紙上的需求錯了可不會叫!

有了能不錯地與真實場景對應,而且「錯了會叫」的需求描述,RD 就可以放心大膽地對程式做任何修改與設計,反正錯了自然有人會跟我說(而且是幾乎馬上)。因此,筆者認為,拿 Unit Test 來描述需求,不是硬規定出來的,而是隨著開發者的經驗累積,在想要不斷提高效率與正確率的動力推進下,自然而然演化出來的結果。

每次與客戶或 PM 溝通需求時你是否會想直接問「你現在情況如何?你想要怎麼進行?你覺得事情變得怎樣會更好?」如果這樣的溝通方式讓你覺得舒服,且理當如此,那我認為 TDD 的開發方式應該很適合你。

謎之聲:「能自然舒服地把事做好就好,不是 TDD 也無妨。」

Reference

  1. TDD:https://en.wikipedia.org/wiki/Test-driven_development
  2. Kent Beck, Extreme Programming Explained, Addison-Wesley Professional, 1999
  3. Kent Beck, Test Driven Development : By Example, Addison-Wesley Signature Series, 2002
tags: ithelp2021

上一篇
Day 17 「提槍上陣」在測試保護下重構出 State 設計模式
下一篇
Day 19 「完美不完美」TDD 的困難之處
系列文
你就是都不寫測試才會沒時間:Kuma 的 30 天 Unit Test 手把手教學,從理論到實戰 (Java 篇)30

尚未有邦友留言

立即登入留言