單元測試的基本概念(2)

　　1、 它的行為和我期望的一致嗎?

　　這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。

　　2、 它的行為一直和我期望的一致嗎?

　　編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致;譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。

　　3、 我可以依賴單元測試嗎?

　　不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。

　　4、 單元測試說明我的意圖了嗎?

　　單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。

　　不寫測試的借口

　　到這里，我們已經知道了使用單元測試的種種理由。但目前的實際情況是大多數程序員不進行單元測試，或只進行簡單的單元測試。下面是一些他們常用的接口：

　　1、 編寫單元測試太花時間了。

　　我們知道，在開發時越早發現BUG，就能節省更多的時間，降低更多的風險。如果你仍然認為在編寫產品代碼的時候，還是沒有時間編寫測試代碼，那么請先考慮下面這些問題：

　　1)、對于所編寫的代碼，你在調試上面花了多少時間。

　　2)、對于以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新確認這些代碼上面。

　　3)、對于一個別人報告的bug，你花了多少時間才找出導致這個bug 的源碼位置。

　　回答完這些問題，你一定不再以“太花時間”作為拒絕單元測試的借口。

　　2、 運行測試的時間太長了。

　　合適的測試是不會讓這種情況發生的。實際上，大多數測試的執行都是非?？斓?，因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時，需要把這些耗時的測試和其他測試分開。通?？梢悦刻爝\行這種測試一次，或者幾天一次。

　　3、 測試代碼并不是我的工作。

　　你的工作就是保證代碼能夠正確的完成你的行為，恰恰相反，測試代碼正是你不可缺少的工作。

　　4、 我并不清楚代碼的行為，所以也就無從測試。

　　如果你實在不清楚代碼的行為，那么估計現在并不是編碼的時候。如果你并不知道代碼的行為，那么你又如何知道你編寫的代碼是正確的呢?

　　5、 但是這些代碼都能夠編譯通過。

　　我們前面已經說過，代碼通過編譯只是驗證它的語法通過。但并不能保證它的行為就一定正確。

　　6、 公司請我來是為了寫代碼，而不是寫測試。

　　公司付給你薪水是為了讓你編寫產品代碼，而單元測試大體上是一個工具，是一個和編輯器、開發環境、編譯器等處于同一位置的工具。

　　7、 如果我讓測試員或者QA(Quality Assurance)人員沒有工作，那么我會覺得很內疚。

　　你并不需要擔心這些。請記住，我們在此只是談論單元測試，而它只是一種針對源碼的、低層次的，為程序員而設計的測試。在整個項目中，還有其他的很多測試需要這些人來完成，如：功能測試、驗收測試、性能測試、環境測試、有效性測試、正確性測試、正規分析等等。

　　8、 我的公司并不會讓我在真實系統中運行單元測試。

　　我們所討論的只是針對開發者的單元測試。也就是說，如果你可以在其他的環境下(例如在正式的產品系統中)運行這些測試的話，那么它們就不再是單元測試，而是其他類型的測試了。實際上，你可以在你的本機運行單元測試，使用你自己的數據庫。

　　總而言之，單元測試會讓我們的開發工作變得更加輕松，讓我們對自己的代碼更加自信。無論是大型項目還是小型項目，無論是時間緊迫的項目還是時間寬裕的項目，只要代碼不是一次寫完永不改動，編寫單元測試就一定超值，它已成為我們編碼不可缺少的一部分。

原文轉自：http://www.uml.org.cn/Test/200603132.htm