May 06 21:46~22:55
(草泥馬也算是馬…XD)
今天先講兩個小故事。以下故事內容純屬虛構,如有雷同實屬不幸,請安心觀看但切勿對號入座。
故事一
鄉民甲到新公司上班,很幸運的該公司的程式設計師跟測試工程師的比率擁有傳說中完美的1:1比率。當鄉民甲告訴同事們,他寫程式的時候會一併寫單元測試,同事們聽了之後大為驚奇並想要勸導他改掉這種「不好的習慣」。
同事:程式設計師自己寫測試程式來測自己的程式(好繞口啊…XD),這樣是會有盲點的。所以我們都不測試自己寫的程式,而是交給測試工程師來測試。
鄉民甲:!#$^%&((()!#$
故事二
鄉民乙的團隊正在導入Scrum,有一天Daily Scrum結束之後,鄉民乙問Scrum Master說:「如果時間不夠,單元測試是不是可以不用測那麼詳細。例如只要寫一個單元測試來測試正常情況下程式能不能動就好了」?
如果你是Scrum Master,你會怎麼回答?
***
突然覺得Teddy是個「不知民間疾苦」的工程師,奇怪了,寫程式一併寫單元測試不是很「自然」的事情嗎?沒有單元測試,日後如何「有膽量」修改自己的程式、加新功能、或是做refactoring。有充足的測試工程師可以協助測試當然很好,但是應該不至於因此而讓程式設計師可以「不用寫」單元測試吧?!有機會很想跟故事一裡面的「虛擬人物」好好的聊一聊這個問題。
第二個問題:「如果時間不夠,單元測試是不是可以不用測那麼詳細」?這個問題比較複雜一點,有幾個思考的方向:
- 先檢討為什麼時間會不夠:是因為sprint planning meeting時沒有把測試的時間給估算進去,或是對於時間的估算過於樂觀,還是因為有突發(沒有估算到)的工作導致時間不夠,抑或是其他原因(例如,不會寫測試案例,或是測試設備不足)。
- 有沒有可能排除上述導致沒時間寫測試的因素:增加撰寫測試案例的時間,增加測試設備,安排時間教導工程師撰寫單元測試的方法等等。
- 就是沒時間--->生出時間來:有些團隊在客戶或是Product Owner「逼迫之下」,每個sprint會過度承諾可以完成的story數量,導致每一個story「看起來」都做完了,但是實際上並沒有(功能看起來完成,但是未經驗證)。要避免這樣的現象,團隊要清楚的定義何謂「Done(做完)」,把撰寫單完測試這件事當成「做完」的條件,否則永遠也不會有時間可以讓工程師去寫單元測試。
***
今年四月十四日在ezScrum團隊所舉辦的Scrum課程中,北科大資工系陳偉凱老師在介紹單元測試的最後,以岳飛所寫的「良馬對」為例告訴學員們為什麼要寫單元測試。
帝問岳飛曰:「卿得良馬否?」
對曰:「臣有二馬,日啗芻豆數斗,飲泉一斛,然非精潔即不受﹔介而馳,初不甚急,比行百里,始奮迅,自午自酉,猶可兩百里,褫鞍甲而不息不汗,若無事然。此其受大而不苟取,力裕而不求逞,致遠之材也。不幸相繼已死。今所乘者,日不過數升,而秣不擇粟,飲不擇泉,攬轡未安,踴躍疾驅,甫百里,力竭汗喘,殆欲斃然。此其寡取易盈,好逞易窮,駑鈍之材也。」
帝稱善。
寫單元測試,雖然「看起來」好像需要花費額外的時間,讓開發速度變慢(然非精潔即不受)。但是就跟岳飛在「良馬對」中所說的良馬一樣,雖然對吃的、喝的很挑,而且剛開始起跑的時候還給我「慢慢來(初不甚急)」,但是在跑了三百里之後卻一副不急不喘,好像沒事的樣子。此為致遠之材也。
如果不寫測試案例,一開始的確是可以跑很快(攬轡未安,踴躍疾驅),但是跑百里之後就沒力累得快死掉了(為什麼沒力?因為程式經常在加新功能或是修改舊功能之後就不能動了,大部分的時間都花在debug上面)。此為駑鈍之材也。
沒想到「良馬對」還可以用在教單元測試上面,陳老師的「扯功」也是挺厲害的…XD。
***
友藏內心獨白:可是良馬的下場卻是「不幸相繼已死」耶…Orz。
陳老師常常會講小故事,很有趣的...XD
回覆刪除Teddy老師也可以用阿兩當教材
回覆刪除To Will Shen:
回覆刪除可能要回家把古文觀止拿出來念...Orz。
To Tony Lin:
用阿兩就有點lo掉了...XD
這個邏輯在台灣不太能成立,因為在生命週期短得根本分不出來良馬劣馬的情況下,又何須挑選致遠之材?
回覆刪除To 匿名:
回覆刪除沒哪麼慘啦,台灣還是有些公司有在開發『生命週期』比較長的軟體啊。
所以軟工這種事情就是這樣囉...重視的就很重視...不重視的就...科科
回覆刪除