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

　　討厭!我一直討厭做測試。測試(單元測試和功能測試)是防礙“真正”工作的事情。每個人都確信自己的代碼是完美的，不是嗎?在確實需要更改代碼的極少數事件中，注釋編寫得如此之好，以致每個人都能領會其中的含義。我需要提高(或許還需要作一些咨詢)。

　　在過去的幾年里，單元測試已成為我編寫軟件的核心環節，多虧了一種稱為極限編程 (XP) 的簡便編程方法(請參閱參考資源)。這種方法要求我為添加的每個函數編寫單元測試，并且要維護這些測試。如果單元測試失敗，我就無法整合任何代碼。隨著代碼庫的不斷增大，這些測試將使開發人員能夠很有把握地完成更改。

　　起初，我認為有了單元測試，就沒必要再進行功能測試。噢，又錯了。功能測試與單元測試相差甚遠。我花了很長一段時間理解二者的區別，以及如何結合使用兩者來改進開發過程。

　　本文探究單元測試與功能測試之間的區別。并概述了在日常開發中使用這兩種測試的方法。

　　測試與開發過程

　　測試對于開發人員極為重要，您必須在開發過程中不斷進行測試。測試不應該只屬于開發周期的某個特定階段。它絕不應該是您將系統交給客戶前要完成的最后一項任務。如何才能知道您何時就完成了所有任務呢?如何才能知道對一個小錯誤的修正是否破壞了系統的主要功能呢?目前想像中的系統如何才能演化為實實在在的系統呢?單元測試和功能測試都應該是開發過程中不可分割的一部分。

　　單元測試應成為您編寫代碼的核心環節，當您所做的項目時限很緊并且您希望控制開發進度時尤其如此。由于單元測試是如此重要，所以您應該先編寫測試，再編寫代碼。

　　一套適當的單元測試具有以下功能：

　　說明可能的最實用設計

　　提供類文檔的最佳格式

　　確定一個類何時完成

　　增強開發人員對代碼的信心

　　作為快速重構的基礎

　　單元測試創建隨系統自然發展的設計文檔。再讀一遍上一句話。文檔隨系統自然發展，這是軟件開發的“圣杯”。有什么方法比通過提供一個用例編碼集來記錄一個類效果更好呢?那就是單元測試：一系列記錄類所做工作的用例代碼，提供輸出控制。這樣，由于單元測試必須通過，所以設計文檔總是最新的。

　　您應該首先編寫測試，然后再編寫代碼。這樣就為要測試的類提供了一種設計，這種設計使您每一時刻都只需集中考慮一小塊代碼。這種做法也使設計變得不再復雜。您沒有試圖為以后著想而實現一些不必要的功能。先編寫測試還使您知道該類何時完成。一旦通過所有測試，任務也就完成了。

　　最后，單元測試可使您高度自信，這又會轉化為開發人員的滿意度。如果只要更改代碼即運行單元測試，您立即就能發現您所做的更改是否對系統造成了破壞。

　　功能測試比單元測試更重要，因為功能測試將驗證系統是否可以發行了。功能測試以一種有用的方式對您的工作系統進行說明。一套適當的功能測試具有以下功能：

　　以有效方式捕獲用戶需求

　　增強小組(用戶和開發人員)在系統滿足用戶需求方面的信心

　　功能測試以有效方式捕獲用戶需求。傳統開發通過用例來捕獲需求。通常，人們討論用例并花很長時間對它們進行細化。他們最后所得到的只是一紙空文。功能測試就像自驗證式用例。極限編程方法可解釋這一概念。XP Stories 將成為未來用戶與開發人員進行溝通的協議。功能測試便是這種溝通的結果。未經功能測試的 Stories 不可能很完善。

　　功能測試填補單元測試留下的空白，并可增強小組對代碼的信心。單元測試漏掉許多錯誤。盡管它可以提供您所需的全部代碼，但它可能無法提供您所需的全部系統功能。功能測試將暴露單元測試遺漏的問題。一套適當的自動化功能測試也不可能捕捉到每個錯誤，但是它能比最好的單一單元測試捕捉更多的錯誤。

　　單元測試與功能測試

　　單元測試向開發人員表明代碼正確執行操作;而功能測試向開發人員表明代碼執行正確的操作。

　　單元測試

　　單元測試是從程序員的角度編寫的。它確保類的某個特定方法成功執行一系列特定的任務。每個測試都確保只要給定輸入，方法將輸出預期的結果。

　　如果沒有測試框架，編寫一套可維護的自動化單元測試幾乎是不可能的。在開始編寫測試之前，請選擇一個小組公認的框架。您將經常性地使用這個框架，因此您最好對它有點好感。極限編程網站提供了幾個單元測試框架(請參閱參考資源)。我最熟悉的框架是 JUnit，它專門用來測試 Java 代碼。

　　功能測試

　　功能測試是從用戶的角度編寫的。這種測試確保系統執行用戶期望它執行的工作。

　　很多時候，系統開發好比建筑房屋。盡管這種類比不很恰當，但為了理解單元測試與功能測試的區別，我們可以擴充這種類比。單元測試好比房屋建筑現場的建筑監理員。他關心房屋的各個內部系統，如地基、構架、供電系統和管道設備等。他確保(測試)房屋每一部分的工作都安全、正常，即符合建筑說明。這種情況下，功能測試類似于視察同一建筑現場的房主。他假定內部系統將正常運作，并假定建筑監理員在執行其任務。房主關心的是住在這所房子里將會怎樣。他關心房子的外觀如何，各個房間的大小是否合適，房子能否滿足家庭的需要，以及窗戶的位置是否有利于采光。房主對房子執行功能測試。他從用戶的角度考慮問題。建筑監理員對房子執行單元測試。他從建筑工人的角度考慮問題。

　　就像單元測試一樣，如果沒有測試框架，編寫一套可維護的自動化功能測試實際上是不可能的。JUnit 非常適合編寫單元測試;但是，當試圖編寫功能測試時，它就顯得力不從心了。就功能測試而言，沒有與 JUnit 相當的框架。也有幾種用于功能測試的產品，但我從來沒見過它們應用于生產環境。如果找不到滿足您的需要的框架，您就必須創建一個。

　　無論我們多么擅長于構建手頭的項目，也不管我們正在創建的系統多么靈活，如果我們的產品不合用，那我們就是白費時間。因此，功能測試是開發最重要的部分。

　　由于兩種測試都必不可少，您就需要了解編寫它們應遵循的原則。

　　如何編寫單元測試

原文轉自：http://www.anti-gravitydesign.com