在開發過程中如何利用單元和功能測試

　　在過去的幾年中，單元測試逐漸成為我編寫軟件的核心內容，在這里要感謝一種叫做極端編程-XP(注1)(見“資源”一節)的簡便程序設計方法。這種方法要求我為新加入的每個函數都編寫單元測試，并且維護這些測試。沒有通過單元測試，我就不能將任何一個的代碼加到模塊中。在代碼基數增長的同時，這些測試允許開發者有依據地將改變集成起來。起初，我認為這些單元測試就足以應付全局，沒有必要涉及到功能測試。噢，又錯了。功能測試和單元測試完全不同的兩者。我花費了很長的時間才理解到兩者的區別，以及如何將它們結合起來，用以改進開發進程。

　　本文探討了單元測試和功能測試之間的差別，同時介紹在你的日常開發的過程中如何來利用它測試和開發過程作為一個開發人員，測試如此之重要，以至于你甚至應該花費幾乎所有的時間來完成它。它不僅需要只被劃分為開發過程中的某個特定階段。顯然，它不該是在你把系統交付給客戶之前完成的最后一項任務。然而，你又如何得知它在何時結束呢?或是你如何得知是否因為修改一個微小的bug而破壞了系統的主要功能呢?或是系統可能會演化成超乎現在想象的模樣?測試，單元的和功能的都應該是開發的過程中的一部分。

　　單元測試應成為你編寫代碼的核心環節，尤其當你在從事一個項目時，緊張的時間約束你的開發進度，你也很想讓它是在可控的有序下進行。我希望測試也是在你編寫代碼之前編寫測試時的重要內容。

　　一套適用的單元測試應具備以下功能：

　　說明可能的最佳適用設計

　　提供類文檔的最佳格式

　　判斷一個類何時完成

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

　　是快速重構的基礎

　　在系統中自然要包含單元測試所需的設計文檔。重新閱讀它，你會發現這是軟件開發進程中的圣杯，文檔跟隨系統的變化而逐步演化。為每一個類提供完備的文檔比起為它提供一系列的使用框架，或是一系列可控的輸入要好得多。這樣，設計文檔就會因為單元測試的逐步通過而隨時更新。

　　你應該在你編寫代碼之前完成編寫測試的工序。這樣做會為測試所涉及的類提供設計方案，并促使你關注代碼中更小的程序模塊。這種練習也會使設計方案變得更加簡單。你不能試圖去了解將來的情形，去實現不必要的功能。編寫測試工作也會讓你清楚類會在什么時間結束?？梢哉f，當所有的測試通過時，任務也就完成了。

　　最后，單元測試會提供給你更高級別的依據，這絕對會滿足開發者的。如果你在改動代碼的同時，進行單元測試，你就會在你破壞的同時立即察覺到事態的發生。

　　功能測試甚至比單元測試更加重要，因為它們說明了你的系統就要預備發布了。功能測試將把你的工作系統放置于一個可用的狀態中。

　　一套適用的功能測試應具備以下功能：

　　有效地掌握用戶的需求

　　向項目組成員(包括用戶和開發者)給出系統面臨這些需求的依據

　　功能測試要在有效地情況下掌握用戶的需求。而傳統的開發者是在使用的過程中發現需求的。通常，人們贊同使用項目工程并且花費相當的時間去重新定制它們。當它們被完成時，它們所得到的僅僅是一堆廢紙。功能測試雷同于自行生效的使用項目的情況。極端程序設計方法(ExtremeProgramming)能夠說明這種概念。XP 的說法就是對未來發生在用戶和開發者之間的交流技巧的描述。功能測試也是這種交流的結果。而沒有功能測試，這種說法也不會建立起來的。

　　功能測試恰好填充了在單元測試和向項目小組提交的代碼依據之間的空隙。單元測試會漏過許多的bug。它可以給出代碼中你所需的所有有效部分，它也會給你所需的整個系統。功能測試可以使單元測試里漏掉的問題曝光。一系列可維護的，自動化的功能測試也會有漏網的情況，但是它至少比獨立地進行最全面的單元測試要有用得多。

　　單元測試VS 功能測試

　　單元測試告訴開發者代碼使事情正確地被執行，而功能測試所說的則是代碼在正確地發揮功效。

　　單元測試

　　單元測試是從開發者的角度來編寫的。它們確保類的每個特定方法成功執行一系列特定的任務。每一個測試都要保證對于給定的一個已知的輸入應該得到所期望的輸出。

　　編寫一系列可維護、自動化、沒有測試框架的單元測試幾乎是不可能的。在你開始之前，選擇一個項目小組都認可的框架。不斷地應用它，逐漸地喜歡它。在極端編程的介紹網頁上(見資源一節)，有很多適用的單元測試框架。我喜歡用的是Juint 來進行Java 代碼的測試。

　　功能測試

　　功能測試則是從用戶的角度來編寫的。這些測試保證系統能夠按照用戶所期望的那樣去運行。很多時候，開發一個完整的系統更像是建造一座大樓。當然，這種比喻并不是完全地恰當，但我們可以擴展它，來理解單元測試和功能測試之間的區別。

　　單元測試類似于一個建筑檢查員對房屋的建設現場進行檢查。他注重的是房屋內部不同的系統，地基，架構設計，電氣化，垂直的線條等等。他檢查房屋的某個部分，以確保它在安全狀態下，正確無誤地工作，即是說，直接針對房屋的代碼。功能測試在這個劇本里類似于房屋的主人在檢查同樣的建設場地。他所期望的是房屋的內部系統正常地運轉，并且房屋檢查員執行了他的任務。房屋的主人看重的是生活在這樣的房屋中會是什么樣子。他關注這間房屋的外貌，不同的房間有合適的空間，房屋適用于家庭的需要，窗戶恰好位于最佳采光的位置。房屋的主人運行的是對房屋的功能測試，他站在用戶的角度上。房屋檢查員運行的是單元測試，他是站在建設者的角度上。

　　象單元測試一樣，編寫一系列可維護、自動化、沒有測試框架的功能測試幾乎是不可能的。Junit在單元測試方面做得很好;然而，它在試圖編寫功能測試時就顯得比較松散。Junit 不等同于功能測試?，F在已經有滿足這個功能的產品問世了，但是我還沒有看到它們被應用于開發產品過程里。如果你不能找到一個測試框架的話，就只好自己創建一個了。無論我們在建立一個項目時多么聰明，建立的系統多么靈活，如果我們的產品不能用，我們就是在浪費時間。結論是，功能測試是開發進程中最重要的一部分。

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