l

2013年4月17日 星期三

因為走過

Apr. 12 14:42~15:28

image

昨天晚上吃飯的時候跟Kay聊到測試的問題。

Teddy:身邊有很多朋友都認為不需要寫單元測試,有些人覺得因為沒有時間所以不寫,有些人認為因為需求還沒穩定,程式會改來改去的,所以還不需要寫。但是我真的很難想像,現在開發軟體如果不寫測試要怎麼進行。

Kay:也不能這麼說,那是因為我們都習慣了要寫單元測試。想當初10幾年前開發軟體,那時候也沒有寫單元測試。

Teddy:說的也是啦,還記得自己剛出社會的時候,那時還沒有JUnit也不知道自動化測試的觀念,程式都是自己用手動的方式測試的。如果遇到的工程師比較細心且負責任,拿到的軟體問題就比較少。記得以前寫的那一堆VB 6的程式,也都是自己用人工測試的方式來確定程式的正確性。

Teddy:後來JUnit「問世」之後,我還花公司的錢買了一套給VB 6使用的單元測試工具,慢慢地很多用VB做出來的DLL我都有寫單元測試。

Kay:可是後來我們用ASP開發的系統,那時候還不知道怎麼做單元測試,也都是靠工程師和PM(專案經理)幫忙測試。

Teddy:對啊,雖然被ASP所呼叫的DLL有單元測試,但是當時還不知道要怎麼幫ASP程式寫單元測試、沒有自動化驗收測試的觀念、沒有Selenium可以用,更不用說幫JavaScript寫單元測試,想都不敢想挑眉質疑

Kay:所以如果能讓還沒體驗過「自動化測試好處」的人親自體驗一次,也許他們的觀念就會改變,那要推行自動化測試也就很簡單了。

Teddy:難就難在怎麼讓他們體驗到好處啊。

***

Teddy有一陣子在幫忙設計architecture prototype(軟體架構雛形),當初的出發點主要是要印證一些概念與想法是否可行。Teddy自己也不確定最後做出來的架構雛形是否可以被改成真正的架構,或是要被丟棄。但是在設計架構雛形的過程中,Teddy還是寫了一些單元測試。為什麼要幫一個架構雛形寫單元測試?因為設計者必須知道自己設計出來的架構雛形是否真的實際可行,而Teddy選擇透過自動化單元測試來驗證這件事情。最後Teddy所設計出來的架構雛形,慢慢地演化成產品的軟體架構。這中間當然經過不少修改與擴充,但所幸有單元測試的幫忙,使得軟體架構演化的過程中,有「第三隻眼」幫忙盯著瞧,避免架構越改越亂的窘況。

最後再補充說明一下,單元測試的數量絕對是隨著時間而成長的。在設計prototype的過程中,一開始所寫的單元測試主要只測試了每個功能的主要成功路徑,並沒有特別去考慮測試涵蓋率的問題。換句話說,要不要寫單元測試、該寫多少數量,並不是一個「0或1的問題」(請參考《0與1的距離》)。

***

日常生活中有太多的難題,放棄了,就沒有;克服了,就升級。

***

友藏內心獨白:怎麼測試的課都開完才寫一堆測試的文章挑眉質疑

3 則留言:

  1. 有些事情其實很簡單,就是懶得寫。另外「體驗到單元測試的好處」不是一件容易的事,特別是當單元測試都還沒寫完,需求就改變,還被嫌沒效率時,就什麼都體驗不到了。

    回覆刪除
  2. To Sprint:

    你這是心情寫照嗎...XD

    『特別是當單元測試都還沒寫完,需求就改變』---> 我覺得這和測試沒有關係,這句話可以改成:『當功能都還沒寫完,需求就改變』,那原本已經寫的功能還是要修改或丟掉啊,照這樣說是不是在尚未確定需求不會改變之前 production code 也不要寫...

    回覆刪除
  3. 這倒不是我的心情寫照,我只是我的觀察(並非只是我現在的公司),其實改需求本來就是要改程式,如果上面能接受先寫單元測試再寫程式對時程帶來的影響,那開發人員就不會被嫌效率不好(單元測試對於整體的貢獻在很多高層眼中是看不到的)。以我原先的例子,雖然需求改了,但先寫production code至少還有能動但不完全對的半成品,上面看起來會比較有效率,單元測試只會看到紅燈,上面只會覺得...。我比較討厭的是web很多東西很難測就是了。

    回覆刪除