讓軟件測試也可以變得有趣的措施(2)

　　剛開始編寫單元測試時很容易恢心。最佳的入手方式就是為新代碼創建單元測試。(盡管為現有代碼創建單元測試比較困難，但并非無法實現)。首先從新代碼著手，待您習慣了整個過程以后，再針對現有代碼創建測試程序。

　　如上文所述，應該首先編寫單元測試，然后再編寫這些單元測試要測試的代碼。如何為尚不存在的代碼編寫測試呢?問得非常好。掌握這一方法需要 90% 的思維加 10% 的技術。我的意思是，您只需假定您正在為其編寫測試的類已經存在。接下來的任務就是編寫測試。起初會犯很多語法錯誤，但您先別管它。這一步您要做的就是定義該類要實現的接口。下一步就是運行您的單元測試，修正語法錯誤(即，編寫一個類，使它實現您的測試剛定義的接口)，并再次運行測試。重復這一過程，每次僅編寫修正故障的代碼。運行測試，直到測試全部通過為止。一旦通過全部單元測試，代碼也就完成了。

　　一般而言，類的每個公共方法都應有一個單元測試。但是，功能簡單的方法(例如，getter 方法和 setter 方法)不需要單元測試，除非它們以某種特別的方式進行獲取和設置。應該遵循下面這條很好的原則：即只要您認為有必要對代碼中的某個行為加注，就編寫一個單元測試。如果您像其他許多程序員一樣不喜歡為代碼加注，則單元測試是記錄代碼行為的一種方法。

　　將單元測試與被測試的相關類放在同一個包內。這種組織方式使每個單元測試都能訪問被測試類中帶有 package 或 protected 訪問修飾符的方法和引用變量。

　　在單元測試中避免使用域對象。域對象是特定于某個應用程序的對象。例如，一個電子表格應用程序可能包含一個注冊對象;這個注冊對象就是一個域對象。如果您有一個已知這些域對象的類，則在測試中完全可以使用這些對象。但是如果您有一個根本不使用這些域對象的類，在測試中就不要將這些對象聯系到該類上。應該避免這種情形完全是因為代碼重用。為某一項目創建的類經常要用于其他項目。重用這些類可能很簡單。但是，如果對重用類的測試中用到了另一個項目的域對象，則使測試能夠正常運行這一工作就會相當耗時。通常情況下，這個測試將被刪除或重寫。

　　這些機制為您提供很好的幫助，但是如果您不運行這些測試，一套綜合的單元測試就變得一文不值。盡早運行測試通常使您在任何時候都對代碼充滿信心。您將隨著項目進展不斷添加功能。運行這些測試將會通知您剛剛實現的新功能是否對系統造成了破壞。

　　在您掌握了編寫單元測試的技巧之后，我們再來看看現有代碼。為現有代碼編寫測試可能是個挑戰。不要為測試而測試。當您發現有必要對一個未經很好測試(或者根本就沒有測試)的類進行修改時，請“隨時”編寫測試?，F在是添加測試的時候了。像往常那樣，該類的單元測試應該捕獲其每個方法的功能。找出應該進行哪些測試的最容易的方法之一是：查看現有代碼中的注釋。任何注釋都應在單元測試內捕獲。將位于方法開頭、說明該方法所起作用的注釋塊翻譯為單元測試。

　　如何編寫功能測試

　　盡管功能測試很重要，但它卻沒有受到足夠的重視。多數項目都有單獨的一個組來做功能測試。通常有一大群人不斷地與系統交互，以確定系統是否正確工作。這種觀念和設置專門的功能測試小組的做法很不明智。

　　對功能測試的處理與對單元測試的處理不應該有太大的區別。只要您編寫的代碼用來產生要求用戶與之交互的組件(如對話框)，就要編寫測試，但實際上編寫測試要在編寫代碼之前進行。請與用戶一起編寫獲取用戶需求的功能測試。無論何時開始一項新任務，都要在功能測試框架中描述此任務。您的開發工作將繼續向前發展，當添加新代碼時，請執行單元測試。當所有的單元測試都結束以后，運行最初的功能測試，看看它是否能夠通過，或者是否需要修改。

　　從理論上講，功能測試小組的概念該消失了。開發人員應與用戶共同編寫功能測試。在對系統所做的一系列功能測試結束之后，開發組中負責功能測試的成員就應該用初始測試的各種變化形式來轟擊系統。

　　單元測試與功能測試的界限

　　通常單元測試與功能測試之間并沒有明確的界限。老實說，有時我也不清楚這個界限在什么位置。在編寫單元測試時，我根據以下原則來確定當前編寫的單元測試實際上是否是功能測試：

　　如果單元測試跨越類邊界，則它就可能是功能測試。

　　如果單元測試變得很復雜，則它可能是功能測試。

　　如果單元測試很脆弱(也就是說，雖然它是一個有效測試，但它必須不斷改變以處理不同的用戶組合)，則它可能是功能測試。

　　如果編寫單元測試比編寫其所測試的代碼更難，則它可能是功能測試。

　　請注意“它可能是功能測試”這一措辭。本文無法提供硬性而快速的規則。單元測試與功能測試中之間有一個界限，但界限的具體位置要由您來確定。您用單元測試用得越熟練，某個特定測試是單元測試還是功能測試的界限就越明顯。

　　小結

　　單元測試是從開發人員的角度出發編寫的，并且關注的是所測試的類的特定方法。當編寫單元測試時，請使用以下這些原則：

　　首先編寫單元測試，然后再編寫要測試的類代碼

　　在單元測試中捕獲代碼注釋。

　　測試所有執行“令人感興趣的”功能(即，不是 getter 和 setter，除非它們以某種獨特的方式執行獲取和設置操作)的公共方法。

　　將每個測試實例與它要測試的類放在同一個包內，以獲得對包成員和保護成員的訪問權。

　　避免在單元測試中使用特定于域的對象。

　　功能測試是從用戶的角度出發編寫的，并且關注用戶感興趣的系統行為。找一個優秀的功能測試框架，或者開發一個測試框架，并使用這些功能測試識別用戶的真實需求。這樣，功能測試人員即可獲得一種自動化工具以及使用這一工具的著手點。

　　使單元測試和功能測試成為您開發過程中的中心環節。如果您這樣做了，您將對系統的運行及擴展充滿信心。如果您沒有這樣做，您對系統就沒有十足的把握。測試可能不那么有趣，但是在開發過程中進行單元測試和功能測試使開發變得相當有趣。

原文轉自：http://www.kjueaiud.com