學習 Unit Test 之二

萬事起頭難，Unit Test 也不例外。在練習使用的過程中，「要如何開始」這個問題困擾了我很久。手上有的是剛寫到一半的值物件類別，不能確定是不是應該替他們寫測試程式。只是單純的檢查「資料記到變數裡」，沒啥意義。經過一些測試，慢慢抓到一些模糊的感覺，在這裡作點記錄。

回到程式的本質，就是處理資料。所以撰寫測試程式就應該是確保「資料被正確地處理」。所以測試程式的輸入和輸出，應該是不一樣的。既使只是數字變成字串，或是物件變成 XML 格式字串都算是改變的一種。當然輸入、輸出的改變可能是數值計算、整理作為 API 回傳值或著是分析、篩選出滿足條件的內容之類，總之，就是「有處理，就有測試」這樣子原則。

所以，一開始建立值物件的時候，不需要寫測試程式。在撰寫由檔案/資料庫讀出、建立值物件時，就要測試來源資料和值物件的內容。當確保了值物件的初始建立後，就可以拿這些建立好的值物件來進行其它運算，分析的工作。這樣，不用在測試程式中一行一行的打程式建物件，把更多的時間用在思考如何驗證結果，撰寫邏輯規則。

沒有資料，就很難進行的模擬的測試。反覆使用程式碼一個個地建立物件，足以消磨一個人的心。而且一旦物件格式改變，那麼需要異動的程式碼可能也會隨著專案發展變多。所以由統一建置的「工廠」來提供資料有是需要的，能夠快速複製新的版本，再修改來滿足其它測試需要。

所以，我覺得測試驅動的程式發展，應該是由值物件，以及建立讀取外部資料來產生值物件的類別開始。接著才會有許多不同變化的資料組合來模擬不同情境。

重構時間

最近回頭看看自己的工作清單，發現有許多事情常常會一拖再拖。不知不覺之間，一兩周就這麼過去了，感覺真是不應該。開始思考發生了什麼事情，讓事情被拖延，或是問題實際上出現在事情的安排上，讓它們本身就具有「容易被拖延」的特質。

觀察了每天時間分配上，有許多片斷但無法控制的時間花費。像是在通勤上遇到塞車，和人相約的等待，回到家等水開，等肉退冰。這些時間不是完全不能預測，卻很容易被人遺忘。當然時間是公平的，把這些時間抽出後，讓我突然發現每天回到家裡的時間少得可憐。如果再加上臨時起意的出門、聚會之類的，感覺上能夠讓人作事情時間實在是不足。

不過，再去看看每天作的事情中，發現有趣的是，一些「真心想作」的事情常被擺著沒動，反倒是遊戲，尤其是手機線上遊戲的進度無論再怎麼忙，似乎都能維持的進度前進的狀態，不會一擺擺上了兩三天。自問自己不是一個容易沈迷遊戲的人，反而是一個無法對遊戲「很認真」的人，所以要作一出「放著遊戲不玩」的決定並不困難。

難不成「不會太認真」，是造成進度能不能持續的原因？當然不是囉！但是太認真，反而會讓事情不容易開始。回想要開始「認真作」一件事情的時候，常常會思考它將需要一段能夠專注、不被輕易打擾的時間，最好還能夠進入所謂的「沈浸」狀態。但是一天之中，會有幾個半小時甚至更長的時間，能夠專注作件事情呢？所以，那些零散破碎的時間反而被「玩個三五分鐘就好」的線上遊戲被佔滿了。

「重構」、「單元測試」的想法又浮上心頭，能不能把想要作的事情，切碎成三五分鐘能成完的片斷？當事情能夠片斷進行，並且能夠容易地在下次接續進行。我想才是能夠滿足現在大多都是破碎時間的合理安排吧！讓想作的事情持續有進度，不會後輕易地被許多小，但不那麼重要的事情瓜分光。

想試著把「重構」用在文章寫作上

我想要寫一些文件，想把自己的一些片斷想法記錄下來，集結成有順序的文章，這樣的想法其實在大學時代就有了。

作為一個新手，所以了解也知道新手在想些什麼，想把解決問題的想法與方式留下來，因為當我不再會犯新手錯誤的時候，我也或多或少地失去了能夠同理新手的心。能夠把這個時期的一些東西記錄下來，我認為有機會能夠幫助未來哪一天某一個新手早一點入門，那麼這就算是有意義的事情。

不過讓人覺得挫折的是，我從來沒能夠好好的把一系列的文章寫完，心中的熱情往往在持續了一兩篇文章之後就漸漸冷下來，反思其中的原因，最主要的是想法隨著時間不斷改變，已經不是一開始構想的架構所考慮到的，因而硬是把新想法塞進不合身的框框，就足以消的磨太多太多的熱情。

回頭想想，這種一系列文章，可能不適合我這種想到什麼打什麼的人在 Blog 上進行連載。還是以單篇，彼此沒緊密連結的內容比較好一些。真的想要弄個有系統的，還是得另外再花一些功夫去作整理。

忽然我發現，原來寫文章，就跟寫程式一樣。耦合度不要太高比較好，越低的耦合能夠給予更高的彈性。因此決定對於一些打了，還不完整的文章進行「重構」，來看看會發生些什麼事情。也許未來還能分享一些所謂的「文章重構」心得。