一、為了單元測試而寫單元測試
最近筆者曾經做過一次“程序員在項目開發中編寫單元測試的情況”的調查。
調查結果顯示：
1. 幾乎沒有嚴格在項目中執行TDD（，TDD）。
2. 為大部份業務方法編寫單元測試，并保證方法測試通過，占16.6%。
3. 偶爾編寫單元測試，一般情況下不寫單元測試，占58.3%。
4. 為了應付項目檢查而寫單元測試，但并不保證方法是否測試通過， 占8.3%。
5. 從來不編寫單元測試，占16.6%。
雖然調查的結果有一定的片面性，但是占58.3%比例的確高的驚人，同時，從來不編寫單元測試16.6%人層也基本反映國內程序員編寫單元測試的狀況，很少有程序員能夠比較認真地去編寫單元測試。那么，到底又是什么原因導致程序員不編寫單元的測試的？根據筆者參與的多個討論，主要有下面幾種原因使程序員不編寫單元測試：
1. 為了完成編碼任務，沒有足夠的時間編寫單元測試。編寫單元測試會導致不能按時完成編碼任務,推遲項目進度。
2. 單元測試的價值不高，完全是浪費時間。
3. 業務邏輯比較簡單，不值得編寫單元測試。
4. 不知道怎么編寫單元測試。
5. 項目沒有要求，所以不編寫。
6. 在項目的前期還是盡量去編寫單元測試，但是越到項目的后期就越失控。
測試常常是程序員十分厭倦的一個項目活動。測試能夠為我們帶來什么？了解這些非常的重要，測試不可能保證一個程序是完全正確的，但是測試卻可以增強我們對程序完整的信心，測試可以讓我們相信程序做了我們期望它做的事情。測試能夠使我們盡早地發現程序的bug和不足。
一個bug被隱藏的時間越長，修復這個bug的代價就越大。在《快速軟件開發》一書中已引用了大量的研究數據指出：最后才修改一個bug的代價是在bug產生時修改它的代價的10倍。
在這里，我們需要討論的重點是單元測試。單元測試是一個方法層級上的測試，單元測試也是最細粒度的測試。用于測試一個類的每一個方法都已經滿足了方法的功能要求。
在現代軟件開發過程中，不管是XP還是RUP都是十分重視單元測試。已經把單元測試作為貫穿整個開發周期的一項重要的開發活動。特別是在現代軟件開發過程中，有經常集成和漸近提交的方法論。由此，總結出了非常好的單元測試理論和實踐。
二、在編寫代碼之前先編寫單元測試,即測試先行
單元測試是代碼的一部份，所有的代碼必須有單元測試，并使測試通過（像在Spring這些優秀的開源項目中在這方面做出了非常好的例子）。
在修改代碼之前先修改單元測試，并使它測試通過。
在編寫代碼之前先編寫單元測試，會帶來非常多的好處。
在編寫代碼之前先編寫單元測試，并不是編寫代碼之前需要一次性為所有的類都事先編寫單元測試，這需要有一個粒度的控制。最大的粒度應該控制在一個類級別上，最合適的粒度是控制在一個方法級別上。先為某一個方法編寫測試代碼，然后再為該方法編寫實現代碼，直到其測試通過后再為另一個方法編寫測試代碼，如此循環。單元測試在這里已經是一個契約規范了，它規范了方法應該做什么、實現什么。測試代碼遠遠要比難以閱讀和不會及時更新的需求文檔更有價值得多。
測試先行，鼓勵對需求的理解。如果沒有理解需求，你是不可能寫出測試代碼的，當然你也不可能寫出好的實現代碼。
測試代碼與其它文檔相比會更有價值。當需求發生改變，實現代碼也相應改變。而往往需求文檔、設計文檔得不到及時更新。測試代碼相比那些過期的文檔更具有價值。
測試先行可以編寫出最大覆蓋率的測試代碼。如果在方法的實現代碼編寫完后再編寫測試代碼，這時開發人員總是編寫一個正確路徑的測試代碼。它已經很難全面的去分析其它分支邏輯。
如果我們采用測試先行，那么就自動地完成了為所有的類都編寫測試。為所有的類都編寫測試會將為你帶來非常多的好處。
我們可以很好地使用自動化測試來測試所有的類，特別是采用日構建的系統�？梢宰屛覀兎判牡貫轭惢蚍椒ㄌ砑有碌墓δ�。我們可以很容易地修改測試代碼并驗證修改后的代碼是有用的代碼�？梢宰屛覀兎判牡貙Υa進行重構和進行設計優化。
重構和設計優化通常會關聯到多個類及多個方法。如果我們為所有的類都編寫了測試，我們就可以在重構代碼后很輕松地進行測試我們的修改是否正確。
為所有的類編寫測試，可以讓我們很容易地修改bug。當接到一個bug報告后，我們總是先修改測試代碼，然后修改實現代碼，使測試成功。這樣不會因為修改一個問題而造成新問題的產生。
良好的單元測試策略給我們增強了對程序的信心,減少了bug的產生及bug的潛伏期，降低修改bug的代價。
單元測試不會是項目開發周期的某一個生命周期，它貫穿于項目的整個生命周期，是一個非常重要的日常開發活動。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
