iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 17
1
Software Development

【Unit Test】Unit Test with C#系列 第 17

【Day 17】輕鬆談-走過一半的鐵人賽

到了今天,以經過了一半的鐵人賽,這次比上次還要久,現在說說目前遇到的狀況及心路歷程。我絕對不會說是因為拖了太久的「待續文」,今天想要偷懶一下!


其實這次主題,一直是心中想要學的項目。開始從事相關工作以來,也已經從一個菜鳥變成一個中鳥(?),不學學點特別的,無法跟下面的人說嘴教導。其實一直覺得Unit test(單元測試)是個很酷的東西,因為自己先前測試都是一連串的動作:上傳檔案➞存到server➞取得檔名➞比較檔名,每次有新的功能加入,或是調整,就要執行多次,而且還要自己準備很多不同的檔名的檔案,而且檔案不能太大,太大要上傳很久。雖然在網路上有看到Unit test相關的事情和TDD,但是完全沒有感受。直到遇到高手同事,才知道他們都有寫Unit test的習慣,雖然涵蓋率*不是100%,但也有50%以上,這時才知道原來Unit test還滿多人使用的。
因此下定決心要學習Unit test,所以先前就買了《The Art of Unit Testing》,可是卻遲遲沒有進度,因此才在這兒用力的推自己一下。

回到正題,走到了第17天,主要的基本功能都已經說的差不多(雖然有兩三篇的程式碼一直都還沒有整理完,push上來),像是stub和mock,還有一些作者認為的程式寫法,都大概說明過。所以可以做基本的處理。
這幾天有稍微使用在工作上,深深的體會到,現實場景與跟隨著書前進是不一樣的。首先,我們程式裡面包含眾多的功能,而書中都是一步一步的蓋起程式碼城堡。但是現實面是:快速的達到目標。先打地基,同時要材料搬到旁邊,蓋城牆時,也順便把大砲放在牆頭上。許多事情都是一起進行,很難可以給自己有時間寫出漂亮的Unit test。
經過那次嘗試的經驗,可以知道自己對於程式功能的切割還不是很透測,所以導致Unit Test很難寫出自己想要的測試內容。但是,在寫Unit Test的時候,會思考自己的程式應當如何寫,以及會有怎樣的預期內容。經過思考後,就會開始整理自己的程式碼,讓他變得更完整且簡便。雖然這樣僅有一兩個小功能,但是也足以讓我衝擊,發現果然跟隨著大師前進,受益良多。這本果然要好好的啃下去。

在這本書可以學到如何切割出程式,寫出比較精簡的程式碼(作者沒深入探討,詳細資料還是要參考別人的著作)。但這個距離還是離我們太遠,這樣會讓我們一頭燒Unit Test,另一頭燒精闢程式碼。
所以近期有稍微研究一下別人寫的文章,比較多實戰說明,像是本屆鐵人賽的TDD教學:TDD - 紅燈,綠燈,重構,30天 TDD之路有你有我或是在網路上看到還滿清楚的教學文:30天快速上手TDD,這些都是有經驗的前輩們寫出來的文章,比我的寫還要更清楚且實用XD 大家可以多多參考。

註:
涵蓋率:就是指Unit Test可以測試程式中在整個程式的比例,越高表示越好,代表幾乎所有程式都可以被測試檢查是否正常運作。當然寫越多會花費越多時間,但是TDD可以解決這個問題(吧XD)。現在IDE大都可以進行估算,可以來看看自己的Unit Test寫得如何囉


上一篇
【Day 16】使用stub 和mock的注意事項
下一篇
【Day 18】初談「隔離框架」(isolation framework)
系列文
【Unit Test】Unit Test with C#31

1 則留言

0
joechh
iT邦新手 5 級 ‧ 2017-12-22 14:44:14

Tony大超棒的阿~~我今年只有當觀眾的份阿!!!

eyelash iT邦新手 5 級‧ 2017-12-22 14:47:20 檢舉

好說好說,這次比較有經驗大概知道如何玩…

不過看到高手留言還是要拜一下,受小的一拜(敬禮)

我要留言

立即登入留言