如何培養單元測試的習慣？怎樣才算一個好的單元測試？

我對單元測試有一定了解，也願意堅持單元測試。但是在實際過程過程中總是不能有效實施，甚至經常無法開展實施。

首先你要明白一點，單元測試不是為了證明你寫的代碼是完美的，而是為了證明你的代碼沒有問題，僅此而已。我們每個程序員都需要對自己敲出來的代碼負責，我們不僅僅要保證代碼可以通過編譯並正常運行，還要滿足需求和設計預期的效果。所以我們驗證代碼是否可以滿足預期的效果的有效手段就是單元測試。但不可置否的是，對於程序員來說做單元測試是一件相當枯燥無趣的事情，而一遍又一遍的測試更是讓人生畏的工作。

以 Java 為例，我們通常使用 JUnit 來進行單元測試，由於我們的單元測試代碼並不會在最終的產品中出現。所以建議大家分別給被測試代碼和單元測試代碼創建相對獨立的目錄，但是要保證測試代碼和被測試代碼使用相同的包名。這樣既保證了代碼的分離，又保證了查找的方便。

我們可以知道，一個 Bug 被隱藏的時間越長，修復這個 Bug 的代價就越大。在《快速軟體開發》一書中已引用了大量的研究數據指出：最後才修改一個 Bug 的代價是在 Bug 產生時修改它的代價的10倍。所以及時的發現 Bug即是成本的控制，又是風險的控制，你也不用手忙腳亂的去查找到底哪裡出了問題。

有句俗話說得好，「一屋不掃，何以掃天下」。同樣的在開發的過程中，一個代碼模塊都不能保證功能的正確性，還怎麼去保證整個工程的質量呢。寫再多的代碼也不過是 Bug，做再多的任務後面也要推翻重來。因此在生產過程中就做好單元測試，控制好單模塊的質量，對整個工程，對你的程序員生涯，都是極其重要的。

看之前寫的代碼大多時候都會覺得需要改進，並且有重構強迫症。

雖然你寫功能的時候多個單測，比不寫單測的人慢些。但是帶來的好處是你的bug少，以後功能改動，你就快了，測試已經自動化了，別人還要一遍一遍的手動測試。