一個需要耗時十分之一秒才能執行完的單元測
這話是認真的。十分之一秒對于單元測試來說簡直就像一個世紀一樣。不信的話讓我們來做一點簡單的算術吧：假設你有一個項目，其中包含3 000個類，每個類平均大約有10個測試，一共算起來就是30 000個測試。倘若這些測試個個都耗時十分之一秒才能運行完的話，那整個項目測試一遍需要多少時間呢?將近一個小時!對于反饋來說這段等待時間可不短。什么?你的項目沒有3 000個類?那一半總有吧，這樣算下來也仍然要等半個小時呢。另一方面，假如我們的測試只需耗時百分之一秒呢?很顯然，我們一下子從需要等一個小時變成了只需等5到10分鐘!這樣的話，雖說我還是比較謹慎的只取出其中的部分單元測試來用，但哪怕每隔幾個小時就將它們全部運行一遍我也不再害怕。
單元測試運行得快。運行得不快的不是單元測試。
有些測試容易跟單元測試混淆起來。譬如下面這些測試就不是單元測試：
(1) 跟數據庫有交互;
(2) 進行了網絡間通信;
(3) 調用了文件系統;
(4) 需要你對環境作特定的準備(如編輯配置文件)才能運行的。
當然，這并不是說這些測試就是壞的。編寫它們常常也是有價值的，而且你通常也會在單元測試用具內來編寫它們。然而，將它們跟真正的單元測試區分開來還是很有必要的，因為這樣你就能夠知道哪些測試是你可以(在你進行代碼修改的時候)快速運行的。
單元測試有下面的這些優點：
1、它是一種驗證行為。
程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發提供支緩。就算是開發后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。
2、它是一種設計行為。
編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試(test-first)，迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。
3、它是一種編寫文檔的行為。
單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。
4、它具有回歸性。
自動化的單元測試避免了代碼出現回歸，編寫完成之后，可以隨時隨地的快速運行測試。
單元測試的范疇
如果要給單元測試定義一個明確的范疇，指出哪些功能是屬于單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的范疇，單元測試所要做的工作。
1、 它的行為和我期望的一致嗎?
這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。
2、 它的行為一直和我期望的一致嗎?
編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致;譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。
3、 我可以依賴單元測試嗎?
不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。
4、 單元測試說明我的意圖了嗎?
單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
