勿以善小而不為

　　勿以善小而不為   單元測試

　　我要不要做單元測試呢?這是一個我被許多人問了許多遍的問題，通常，這個問題會出現在討論TDD的時候，在提問者眼中：

　　一眼就能看明白，不值得測

　　單元測試粒度太細

　　單元測試要寫好多，耽誤工作量

　　單元測試不穩定

　　人員能力有限，寫不好單元測試

　　正是因為這樣的原因，在他們看來，系統測試也許是一個更好的選擇。我不否認系統測試的重要性，但是，單元測試才是他們最應該做好的。

　　程序員和程序員之間的差異很大程度上是由開發習慣決定的。Kent Beck曾自我評價，“我不是什么偉大的程序員，我只是一個有著很多好習慣的程序員”。單元測試就是一個好習慣。它等于要開發人員在編碼的時候就要驗證代碼的正確性，而不是向后拖。軟件開發最基本的一條規律是，越往后做，代價越大。正確性總要驗證，那當然是越早驗證越好。

　　如果你做過單元測試，你就會發現，一旦開始考慮驗證，很多之前不曾考慮過的問題就會浮出水面，比如，一些邊界條件。單元測試給了我們一個更仔細的關注質量的機會。雖然我們不能說經過單元測試的代碼就是100%的完美，但是，我們至少給出了力所能及的驗證。而事實上，一旦到更高層面的驗證，比如系統測試，比如測試人員的測試，這些所謂的細枝末節是很難覆蓋到的。而這些地方又恰恰是很多開發人員認為簡單的，不值得測的地方。一旦遺漏，就會成為產品的缺陷，隨時可能爆發。

　　有人曾給過我們這樣一個數據，他們的產品中有15%的bug源自像變量賦值這樣非常簡單的錯誤。從這個數據可以看出，很多人還做好自以為很簡單的事。程序員有自信是好事，但前提是要有自信的本事。單元測試給了開發人員一個一步一個腳印，踏踏實實走路的機會。當每個構造快都經過驗證的之后，把它們組合在一起，我們只要驗證他們之間組合就好了。這樣的做法，每一步心里都是有底的。而現在的很多開發給人的感覺是在撞大運。

　　時至今日，還有很多程序員把開發完成理解成“編碼完成”。行百里者半九十，這句話就是給這樣的程序員預備的。他們以為自己代碼寫到90%的時候，其實，后面還有一大半的驗證工作等著他們。這些程序員只不過在用有另外一個名字——比如集成——的時間去做他們份內的工作，而某些愚笨的老板居然認為這是天經地義的，所以，他們會壓縮編碼時間，給后面的驗證留下更長的時間，于是，開發人員的時間更緊張了，他們更傾向于前期少驗證，一個惡性循環就此形成。

　　對于很多人來說，單元測試有問題，但實際上，真正有問題的是代碼。為什么測試不好做，因為代碼的耦合太大了。為什么單元測試不穩定，因為設計不穩定。談到這里，我得承認一點，想把這一切都做好，人是關鍵。不是所有人都能拆解好代碼的，但這里真正的問題是，不是所有人都有意識去拆解代碼的，那些代碼里面的垃圾就是從這里產生的。很多自以為是建設者的人，實際上，是添亂的。

　　或許你會說，有很多高手都認為單元測試不是必要的，確實如此，但你光看見賊吃肉了，那些高手個人能力超強，基礎扎實，思維縝密，先跟人家比這些東西吧!對于軟件開發人員來說，單元測試就是基本功，通過它，可以讓人在很多方面得到很多鍛煉。先把基本功打扎實再琢磨別的吧!

原文轉自：http://www.kjueaiud.com