為什么要進行單元測試？ 單元測試保證局部代碼的質量 單元測試在隔離的前提下，分別對各個代碼單元進行測試，能夠達到其他測試不可能達到的測試完整性，從而保證了局部代碼的質量。只有局部代碼的質量得到了保證，軟件產品的質量才可能得到保證。 單元測試改良項目代碼的整體結構 要對代碼進行單元測試，最起碼的前提是代碼能夠隔離，也就是說，要具有一定的可測性，因此，單元測試是一種有效的約束機制，這種機制將有效地改良代碼的整體結構。例如，如果把業務代碼直接寫在界面類中，將很難進行單元測試，隨意的不合理的緊耦合也會造成難于測試，單元測試使這些不好的特性得于及時發現，從而很容易進行修正?？蓽y性是高質量代碼的首要特性，不具有可測性，也就無法衡量代碼的正確性，有了可測性，也就基本上保證了代碼的可擴展性、可復用性。 單元測試降低測試、維護升級的成本 錯誤越早發現，修復的代價越小，另一方面，如果代碼經過了充分的單元測試，集成測試和系統測試就只需要關注設計方面的問題。自動回歸測試也大量降低升級維護成本。 使開發過程適應頻繁變化的需求 單元測試自然地使開發流程變得“敏捷”，這是因為，整體結構良好的代碼具有較好的可擴展性，自動回歸測試又能保證修改不會引入新的錯誤，因此可以適應頻繁變動的需求，降低系統分析、架構設計和后期測試的壓力。 單元測試有助于提升程序員的能力 對程序員來說，單元測試有利于養成縝密的思維習慣，及提高設計能力。 由誰進行測試？開發部門還是測試部門？ 應該由開發部門進行單元測試！ 由測試部門進行單元測試的問題 代價高：反復的重新理解代碼需要大量的時間，反復的溝通也需要大量的成本。 人手不足：進行單元測試的人員需要具備編碼能力，很多軟件企業的測試部門都沒有足夠的人手。 耽誤了測試部門對其他測試的準備工作：編碼階段，測試部門要為集成測試、系統測試等做好準備，如果測試部門陷在單元測試的“泥潭”里，很可能影響這些準備工作。 由開發部門進行單元測試的問題 擔心影響開發進度：這是現實問題，但自動化的單元測試工具可以解決這個問題。 程序員不習慣做單元測試：這種習慣是可以理解的，但并不難改變，實際上，程序員寫程序時都是要進行測試調試的，只不過通常比較零散和隨意而已。 測試自己編寫的代碼，難于保證測試的效果：測試自己寫的代碼，通常會只測試正常的輸入，因此難于保證測試的完整性，但自動化的單元測試工具，可以統計白盒覆蓋，甚至提供用于找出遺漏的測試用例的工具，達到很高的測試完整性。只要達到了足夠的測試完整性，那么，無論誰測試，效果都是一樣的。 無論由哪個部門做單元測試，都要面對一些問題，但開發部門所面對的問題可以借助工具來解決，而由測試部門進行單元測試，要么無法真正實施，要么代價昂貴。 由測試部門進行單元測試為什么成本昂貴？ 需多次重復理解程序 測試人員進行單元測試時必須理解程序功能甚至代碼邏輯；充分的單元測試通常會發現很多細小的錯誤，程序員修改代碼時，又要再次理解程序。理解程序是很耗費時間的。 反復溝通需要大量時間成本 單元測試發現的錯誤一般是小Bug，但數量可能很多，修改錯誤一般由程序員進行，測試人員還要確認，這些反復溝通也需要很多的時間。 不利于發揮單元測試對代碼結構的約束機制 如果等編碼基本完成再由測試部門進行單元測試，也就不能及時發揮單元測試對代碼整體結構的約束效果，測試部門拿到代碼時，往往會發現難于測試。 耽誤測試部門對其他測試的準備工作： 編碼階段，測試部門要為集成測試、系統測試等做好準備，如果測試部門陷在單元測試的“泥潭”里，很可能影響這些準備工作。 基于以上理由，即使測試部門人手充裕，僅僅從效益來考慮，也不應該由測試部門進行單元測試。如果測試部門本來就人力不充裕（進行單元測試的人員需具備編碼能力），勉強由測試部門進行單元測試，結果往往是----沒有結果。 由開發部門進行單元測試能保證測試效果嗎？ 程序員測試自己編寫的代碼，往往只考慮“正常狀況”，這當然會影響測試效果。但如果所用的單元測試工具能夠統計各種白盒覆蓋率，就能檢查測試效果。當然，只做到這一點還是不夠的，因為白盒覆蓋具有逾后逾難的特點，達到一定的覆蓋率后，覆蓋率的提升會很困難。如果測試工具功能足夠強大，能提供工具幫助用戶快速地設計測試用例，達到完整的白盒覆蓋，那么測試效果就能得到完全的保證。 實際上，如果沒有充分的統計數據，沒有達到足夠的測試完整性，那么由誰做單元測試，效果都不能保證。 進行單元測試，關鍵是要達到比較高的輸入覆蓋，這樣，無論由誰測試，效果都是一樣的。