在開發過程中怎樣利用單元和功能測試

這種方法要求我為新加入的每個函數都編寫單元測試，並且維護這些測試。沒有通過單元測試，我就不能將任何壹個的代碼加到模塊中。在代碼基數增長的同時，這些測試允許開發者有依據地將改變集成起來。起初，我認為這些單元測試就足以應付全局，沒有必要涉及到功能測試。噢，又錯了。功能測試和單元測試完全不同的兩者。我花費了很長的時間才理解到兩者的區別，以及如何將它們結合起來，用以改進開發進程。本文探討了單元測試和功能測試之間的差別，同時介紹在妳的日常開發的過程中如何來利用它測試和開發過程作為壹個開發人員，測試如此之重要，以至於妳甚至應該花費幾乎所有的時間來完成它。它不僅需要只被劃分為開發過程中的某個特定階段。顯然，它不該是在妳把系統交付給客戶之前完成的最後壹項任務。然而，妳又如何得知它在何時結束呢？或是妳如何得知是否因為修改壹個微小的bug而破壞了系統的主要功能呢？或是系統可能會演化成超乎現在想象的模樣？測試，單元的和功能的都應該是開發的過程中的壹部分。單元測試應成為妳編寫代碼的核心環節，尤其當妳在從事壹個項目時，緊張的時間約束妳的開發進度，妳也很想讓它是在可控的有序下進行。我希望測試也是在妳編寫代碼之前編寫測試時的重要內容。壹套適用的單元測試應具備以下功能：說明可能的最佳適用設計提供類文檔的最佳格式判斷壹個類何時完成增強開發人員對代碼的信心是快速重構的基礎在系統中自然要包含單元測試所需的設計文檔。重新閱讀它，妳會發現這是軟件開發進程中的聖杯，文檔跟隨系統的變化而逐步演化。為每壹個類提供完備的文檔比起為它提供壹系列的使用框架，或是壹系列可控的輸入要好得多。這樣，設計文檔就會因為單元測試的逐步通過而隨時更新。妳應該在妳編寫代碼之前完成編寫測試的工序。這樣做會為測試所涉及的類提供設計方案，並促使妳關註代碼中更小的程序模塊。這種練習也會使設計方案變得更加簡單。妳不能試圖去了解將來的情形，去實現不必要的功能。編寫測試工作也會讓妳清楚類會在什麽時間結束。可以說，當所有的測試通過時，任務也就完成了。最後，單元測試會提供給妳更高級別的依據，這絕對會滿足開發者的。如果妳在改動代碼的同時，進行單元測試，妳就會在妳破壞的同時立即察覺到事態的發生。功能測試甚至比單元測試更加重要，因為它們說明了妳的系統就要預備發布了。功能測試將把妳的工作系統放置於壹個可用的狀態中。壹套適用的功能測試應具備以下功能：有效地掌握用戶的需求向項目組成員（包括用戶和開發者）給出系統面臨這些需求的依據功能測試要在有效地情況下掌握用戶的需求。而傳統的開發者是在使用的過程中發現需求的。通常，人們贊同使用項目工程並且花費相當的時間去重新定制它們。當它們被完成時，它們所得到的僅僅是壹堆廢紙。功能測試雷同於自行生效的使用項目的情況。極端程序設計方法（ExtremeProgramming）能夠說明這種概念。XP 的說法就是對未來發生在用戶和開發者之間的交流技巧的描述。功能測試也是這種交流的結果。而沒有功能測試，這種說法也不會建立起來的。功能測試恰好填充了在單元測試和向項目小組提交的代碼依據之間的空隙。單元測試會漏過許多的bug。它可以給出代碼中妳所需的所有有效部分，它也會給妳所需的整個系統。功能測試可以使單元測試裏漏掉的問題曝光。壹系列可維護的，自動化的功能測試也會有漏網的情況，但是它至少比獨立地進行最全面的單元測試要有用得多。單元測試VS 功能測試單元測試告訴開發者代碼使事情正確地被執行，而功能測試所說的則是代碼在正確地發揮功效。單元測試單元測試是從開發者的角度來編寫的。它們確保類的每個特定方法成功執行壹系列特定的任務。每壹個測試都要保證對於給定的壹個已知的輸入應該得到所期望的輸出。編寫壹系列可維護、自動化、沒有測試框架的單元測試幾乎是不可能的。在妳開始之前，選擇壹個項目小組都認可的框架。不斷地應用它，逐漸地喜歡它。在極端編程的介紹網頁上（見資源壹節），有很多適用的單元測試框架。我喜歡用的是Juint 來進行Java 代碼的測試。 功能測試功能測試則是從用戶的角度來編寫的。這些測試保證系統能夠按照用戶所期望的那樣去運行。很多時候，開發壹個完整的系統更像是建造壹座大樓。當然，這種比喻並不是完全地恰當，但我們可以擴展它，來理解單元測試和功能測試之間的區別。單元測試類似於壹個建築檢查員對房屋的建設現場進行檢查。他註重的是房屋內部不同的系統，地基，架構設計，電氣化，垂直的線條等等。他檢查房屋的某個部分，以確保它在安全狀態下，正確無誤地工作，即是說，直接針對房屋的代碼。功能測試在這個劇本裏類似於房屋的主人在檢查同樣的建設場地。他所期望的是房屋的內部系統正常地運轉，並且房屋檢查員執行了他的任務。房屋的主人看重的是生活在這樣的房屋中會是什麽樣子。他關註這間房屋的外貌，不同的房間有合適的空間，房屋適用於家庭的需要，窗戶恰好位於最佳采光的位置。房屋的主人運行的是對房屋的功能測試，他站在用戶的角度上。房屋檢查員運行的是單元測試，他是站在建設者的角度上。象單元測試壹樣，編寫壹系列可維護、自動化、沒有測試框架的功能測試幾乎是不可能的。Junit在單元測試方面做得很好；然而，它在試圖編寫功能測試時就顯得比較松散。Junit 不等同於功能測試。現在已經有滿足這個功能的產品問世了，但是我還沒有看到它們被應用於開發產品過程裏。如果妳不能找到壹個測試框架的話，就只好自己創建壹個了。無論我們在建立壹個項目時多麽聰明，建立的系統多麽靈活，如果我們的產品不能用，我們就是在浪費時間。結論是，功能測試是開發進程中最重要的壹部分。因為兩種類型的測試都是必要的，妳會需要編寫它們的指南。如何編寫單元測試 在妳開始編寫單元測試很容易被激動的情緒感染。最簡單的起步方式就是為新的代碼創建單元測試。為已經存在的代碼創建單元測試是壹種比較有難度的開始方式，但是也是可行的。）從新的代碼開始，習慣了這樣的步驟後，還要堅持重新閱讀現有代碼，並為它們創建壹套測試程序。就像前面提到過的壹樣，妳應該在妳編寫要測試的代碼之前編寫單元測試。如何做到為還不存在的事物編寫測試呢？好問題！掌握這個能力需要90％的智力和10％技巧。我的意思是妳只需假裝是在為已有的類編寫測試。接下來，進行編寫的工作。最初，妳將出現很多語法錯誤，但是let it be，不要理會它。緊接著進行單元測試，修改語法錯誤（即是說，只用妳自己定義的測試接口來實現類），再壹次進行測試。重復這個過程，每壹次都寫下充足的代碼去修改錯誤，進行測試直到它們通過為止。當所有的單元測試都通過時，代碼才算真正地完成了。壹般地說，妳的類應具有開放的單元測試方式。然而，帶有直截了當的功能性的方法比如說，Java 語言裏的Getting 和Setting 讀寫方法，就不需要單元測試，除非它們是以“特殊”的方式進行的。接下來的指導就是，當妳感到需要對代碼中的某些特性添加註釋時，同時要編寫出單元測試。如果妳同很多的程序員壹樣，厭惡為代碼寫註釋，單元測試就是將妳的代碼的特性文檔化的壹種好方法。將單元測試同被測試的相關的類打包在壹起。（這種組織的方式允許每壹個單元測試都能夠直接訪問類中被打包和保護的方法和參數）。要避免在單元測試中用到域對象（domain object）。域對象就是對於壹個應用程序特定的對象。例如，電子表格應用程序有個工作簿對象，它就是壹個域對象。如果妳的壹個類已經知道了域對象，在妳的測試中用到這些對象是很好的。但是如果妳的類沒有涉及到這些對象，就不要在測試裏讓它們同類糾纏不清了。不這樣做的話，就會產生打包的代碼被重用。經常是為壹個項目創建的類也可以應用於其他的項目，這樣可能會出現直接重用這些類的情況。但是如果針對這些類的測試也用於另外的項目對象，讓測試生效會很費時，通常測試不是被拋棄掉就是被重新編寫。以上的壹些技巧會讓妳從中受益，但最重要的是如果妳不實際地去做，就永遠不會對單元測試有全面、深入的理解。更早地運行測試，並且在整個過程中都在代碼中給出全面的依據。當項目進展時，妳會隨時添加更多的特性。運行測試就會提醒妳，實現剛添加的特性會不會破壞已有的東西。在妳已經掌握編寫單元測試的技巧之後，妳需要重新閱讀已存在的代碼。的確，為它們編寫代碼可能會是壹場挑戰。但是千萬不要為了測試的目的而測試。可以說，編寫測試是壹件緊跟時效的事情，尤其是當妳發現要修改壹個沒有好的測試程序的類時，那就是添加測試的恰當時機。和平常壹樣，單元測試應該具備類每個方法的特性。實現測試的壹個最簡單的方法就是，測試的同時壹定要註意代碼的註釋。在單元測試中，不能放過任何壹個註釋，在描述測試方法的開始就要為單元測試添加大量的註釋中。如何編寫功能測試盡管功能測試是如此重要，它也有個開發過程裏醜陋的繼生子的壞名聲。在大多數的項目裏，是由壹個獨立的工作組來完成功能測試的工作。通常需要壹群人在系統中的相互協助才能保證工序的正確運行。這種通常的看法和隊伍的組建的做法，都是非常愚蠢的。功能測試同單元測試相類似。壹旦要編寫有用戶涉入的產品的代碼（例如，對話框）時，就要編寫測試，但是壹定要在實際編寫代碼之前做。壹旦妳開始了壹項新任務，就要在功能測試的框架裏清楚地描述這個任務的內容。妳加入的新代碼的同時進行單元測試，開發工作就向前持續進行。當所有的單元測試都進行通過後，再進行最初的功能測試來判斷項目是否可以通過，或是需要修改。理想的狀況下，功能測試小組的概念應該不存在的。開發者應該同用戶壹同編寫功能測試。系統通過了壹系列的單元測試後，負責進行功能測試的小組成員就要改變初試測試的參數，再進行系統的功能測試。單元測試和功能測試之間的界線 壹般情況下，很難劃清在單元測試和功能測試之間的界限。說實話，壹直以來，我就不知道這個界線應該定在哪裏。當編寫單元測試時，我用以下幾個方法來判定單元測試是不是已經變成了功能測試： 如果單元測試超越了類之間的界限，它可能變成了功能測試 如果單元測試變得非常的復雜，它可能變成了功能測試 如果單元測試變得很脆弱（即是說，它已經成為壹個測試，但是卻因為要迎合不同用戶需求的改變而被動地變化），它可能變成了功能測試 如果單元測試比需要測試的代碼還要難於編寫，它可能變成了功能測試註意“它可能變成了功能測試”的說法，在這裏沒有嚴格的標準。在單元測試和功能測試之間是有界線的，但是妳必須自己判定它在哪裏。單元測試進行地順利，特定的測試逾越兩者界線的過渡就越明顯。結論單元測試以開發者的角度來編寫，並註重被測試類的特性。當編寫單元測試時，利用以下幾條指導：在類代碼進行測試之前編寫單元測試在單元測試裏掌握代碼的註釋測試所有執行特定功能的公用程序（即是說，和Java 語言中的Getting 和Setting 讀寫方法不同的方法。除非它們是通過壹種特殊的方式來完成Getting 和Setting 功能的。）將所有的測試項目同被測試的類打包在壹起，並且分配它們對在模塊包內的和被保護成員的訪問權限在單元測試中避免使用某些特定的對象功能測試也需要從用戶的角度出發來編寫，並且註重用戶所感興趣的系統功能。選擇壹個適當的功能測試框架，或是開發出壹種，並利用這些功能測試來制定用戶們想要的東西。通過這種方式，功能測試的人員可以獲得壹個自動的工具，並且對使用工具的習慣有了壹個好的起點。將單元測試和功能測試作為開發進程的核心內容。這樣做，妳就會確定系統在正常運轉。如果沒有，妳恐怕不能保證系統是正常工作的。測試可能不是壹件好玩的事情，但是從事單元測試和功能測試會使開發過程裏含有更多的樂趣。資源“利用Ant 和JUnit 改進開發過程”（開發工作，2000 年12 月）揭示了單元測試的益處，尤其是應用了Ant 和Junit 之後。開始了解極端編程的方法從極端編程的網頁上下載各種單元測試的框架文章出處