全面分析持續集成優缺點(3)

XP將測試分爲兩類：單元測試和容納測試（也叫功能測試）。單元測試是由開發者自己編寫的，通常只測試一個類或一小組類。容納測試通常是由客戶或外部的測試組在開發者的幫助下編寫的，對整個系統進行端到端的測試。這兩種測試我們都會用到，並且儘量提高測試的自動化程度。

　　作爲創建的一部分，我們需要運行一組被稱爲"BVT"（Build Verification Tests，創建確認測試）的測試。BVT中所有的測試都必須通過，然後我們才能宣佈得到了一個成功的創建。所有XP風格的單元測試都屬於BVT。由於本文是關於創建過程的，所以我們所說的"測試"基本上都是指BVT。請記住，除了BVT之外，還有一條測試線存在（譯註：指功能測試），所以不要把BVT和整體測試、QA等混爲一談。實際上，我們的QA小組根本不會看到沒有通過BVT的代碼，因爲他們只對成功的創建進行測試。

　　有一條基本的原則：在編寫代碼的同時，開發者也應該編寫相應的測試。完成任務之後，他們不但要歸還（check in）產品代碼，而且還要歸還這些代碼的測試。這也跟XP的"測試第一"的編程風格很相似：在編寫完相應的測試、並看到測試失敗之前，你不應該編寫任何代碼。所以，如果想給系統添加新特性，你首先應該編寫一個測試。只有當新的特性已經實現了以後，這個測試纔可能通過。然後，你的工作就是讓這個測試能夠通過。 [Page]

　　我們用Java編寫這些測試，與開發使用同樣的語言，所以編寫測試與編寫代碼沒有太大的區別。我們使用JUnit（http://www.junit.org/）來作爲組織、編寫測試的框架。JUnit是一個簡單的框架，讓我們可以快速編寫測試、將測試組織爲套件、並以交互或批處理的模式來運行測試套件。（JUnit是xUnit家族的Java版本--xUnit包括了幾乎所有語言的測試框架。）

　　在編寫軟件的過程中，在每一次的編譯之後，開發者通常都會運行一部分單元測試。這實際上提高了開發者的工作效率，因爲這些單元測試可以幫助你發現代碼中的邏輯錯誤。然後，你就沒必要去調試查錯，只需要注意最後一次運行測試之後修改的代碼就行了。這個修改的範圍應該很小，所以尋找bug也就容易多了。

　　並非所有的人都嚴格遵循XP"測試第一"的風格，但是在第一時間編寫測試的好處是顯而易見的。它們不但讓每個人的工作效率更高，而且由這些測試構成的BVT更能捕捉到系統中的錯誤。因爲BVT每天要運行好幾次，所以BVT檢查出的任何問題都是比較容易改正的，原因很簡單：我們只做了相當小範圍的修改，所以我們可以在這個範圍內尋找bug。在修改過的一小塊代碼中排錯當然比跟蹤整個系統來排錯要有效多了。

　　當然，你不能指望測試幫你找到所有的問題。就象人們常說的：測試不能證明系統中不存在錯誤。但是，盡善盡美不是我們唯一的要求。不夠完美的測試只要經常運行，也比永遠寫不出來的"完美測試"要好得多。

　　另一個相關的問題就是：開發者們爲自己的代碼編寫測試。我們經常聽人說：開發者不應該測試自己的代碼，因爲他們很容易忽視自己工作中的錯誤。儘管這也是事實，但是自測試過程需要快速將測試轉入代碼基礎中。這種快速轉換的價值超過獨立測試者的價值。所以，我們還是用開發者自己編寫的測試來構造BVT，但是仍然有獨立編寫的容納測試。

　　自測試另一個很重要的部分就是它通過反饋--XP的一項核心價值--來提高測試的質量。這裏的反饋來自於從BVT中逃脫的bug。自測試的規則是：除非你在BVT中加入了相應的測試，否則就不能修正任何錯誤。這樣，每當要修正某個錯誤的時候，你都必須添加相應的測試，以確保BVT不會再把錯誤放過去。而且，這個測試應該引導你去考慮更多的測試、編寫更多的測試來加強BVT。

主創建

　　創建過程的自動化對於單個開發者來說很有意義，但是它真正發光的，還是在整個系統的主創建（master build）的生成。我們發現，主創建過程能讓整個團隊走到一起來，讓他們及早發現集成中的問題。

　　第一步是要選擇運行主創建的機器。我們選擇了一臺叫做"投石車"的計算機（我們經常玩"帝國時代"J），這是一臺裝有四個CPU的服務器，非常適合專門用來做創建。（由於完整的創建需要相當長的時間，所以這種馬力是必須的。）

　　創建進程是在一個隨時保持運行的Java類中進行的。如果沒有創建任務，創建進程就一直循環等待，每過幾分鐘去檢查一下代碼倉庫。如果在最後的創建之後沒有人歸還任何代碼，進程就繼續等待。如果代碼倉庫中有了新的代碼，就開始創建。

　　創建的第一階段是完全提取倉庫中的代碼。Starteam已經爲我們提供了相當好的Java API，所以切入代碼倉庫也很容易。守護進程（daemon）會觀察五分鐘以前的倉庫，看最近五分鐘裏面有沒有人歸還了代碼。如果有，守護進程就會考慮等五分鐘再提取代碼（以免在別人歸還代碼的過程中提取）。 [Page]

　　守護進程將全部代碼提取到投石機的一個目錄中。提取完成之後，守護進程就會在這個目錄裏調用Ant腳本。然後，Ant會接管整個創建過程，對所有源代碼做一次完整的創建。Ant腳本會負責整個編譯過程，並把得到的class文件放進六個jar包裏，發佈到EJB服務器上。

　　當Ant完成了編譯和發佈的工作之後，創建守護進程就會在EJB服務器上開始運行新的jar，同時開始運行BVT測試套件。如果所有的測試都能正常運行通過，我們就得到了一個成功的創建。然後創建守護進程就會回到Starteam，將所有提取出的源代碼標記上創建號。然後，守護進程會觀察創建過程中是否還有人歸還了代碼。如果有，就再開始一次創建；如果沒有，守護進程就回到它的循環中，等待下一次的歸還。

　　創建結束之後，創建守護進程會給所有向最新一次創建歸還了代碼的開發者發一個e-mail，彙報創建的情況。如果把創建留在代碼歸還之後去做，而又不用e-mail向開發者通報創建的情況，我們通常認爲這是不好的組織形式。

　　守護進程將所有的步驟都寫在XML格式的日誌文件裏面。投石車上會運行一個servlet，允許任何人通過它檢查日誌，以觀察創建的狀態。（見圖1）

　　屏幕上會顯示出創建是否正在運行、開始運行的時間。在左邊有所有創建的歷史記錄，成功的、失敗的都記錄在案。點擊其中的某一條記錄，就會顯示出這次創建的詳細信息：編譯是否通過、測試的結果、發生了哪些變化……