因為走過

Apr. 12 14:42~15:28

昨天晚上吃飯的時候跟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的距離》）。

***

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

***

友藏內心獨白：怎麼測試的課都開完才寫一堆測試的文章。