自動化測試（automated testing）在好多書籍中被介紹了，但很少注意講怎樣去組織這些測試。當(dāng)測試寫的越多時，很難知道把這些測試放到哪或者用什么去調(diào)用它們。 在極限編程---Extreme Programming(xp)，測試驅(qū)動開發(fā) Test-Driven Development (TDD)盛行的時代，這成了一個很大的問題。 你可以把 測試驅(qū)動開發(fā)（TDD）認為是"Development through testing" 開發(fā)由經(jīng)測試。

    TDD的主要條款：

    在任何代碼片段之前，必須先寫好自動檢測這段代碼功能的程序。既然代碼不存在，那么測試在一開始失敗。

    在測試通過之后，復(fù)制的代碼必須刪掉。

    象這樣的方式每個程序員都可以應(yīng)用，并不需要特定的方法論。但在我們開始寫test之前， 值得我們注意的是，先考慮一下如何組織自動化測試。

    這里有幾種我們需要考慮的測試

    單元測試(Unit test) :這些是為檢查個別模塊（比如classes類）服務(wù)的。 如果對象需要訪問外部的數(shù)據(jù)源，比如Database，需要通過一些模擬的對象（MOCK object）來模擬Database， （但這也只有在真實環(huán)境的數(shù)據(jù)與測試環(huán)境不同的時候。

    比如測試環(huán)境里面沒有真實Datebase，需要MOCK Object）

    用戶測試 （Customer's test）:這里是功能的，系統(tǒng)的并且認可的測試。系統(tǒng)中所有的行為檢查都做為一個整體。 在XP理論中，這些測試，是由用戶編寫的，給出測試案例提綱。

    集成測試 （Itegration tests）: 這些測試象是在用戶測試和單元測試之間的十字路口。 集成測試幫助程序測試幾個級別中交互。Mock Object不會出現(xiàn)在集承測試中，他會增加測試時間。同樣，集成測試也經(jīng)常需要存在的特定的測試環(huán)境，比如從數(shù)據(jù)庫中放一些測試數(shù)據(jù)。集成測試也許使用外部的lib。 Cactus是這樣一個J2EE集成的lib。 解釋這些測試已經(jīng)超出了本篇文章的范圍，并且也需要詳細的理論敘述，所以，你僅需要知道這種測試存在可以了。

    開發(fā)測試（Developer's test） : 這種測試是那些開發(fā)者校驗 整段代碼，新加的代碼，新加的函數(shù)函數(shù)。 對于每個開發(fā)而言， 隨時生成新的的測試去檢查代碼是很重要的。 組織這些測試和組織這些代碼有著同樣的重要性。

    至于本文其他地方，只要說到"測試"，是專指開發(fā)測試（Developer's test）。

    在開發(fā)期間， 一個程序員有時可能問自己：系統(tǒng)中這個行為有test么，這個test存在么，哪里可以找到這個test？每次發(fā)現(xiàn)錯誤，都是靠基礎(chǔ)修改bug而不是通過自動測試，這是一個典型的例子。 在這種情形下事情進展可能是：

    去找到這個函數(shù)的測試（可能測試已經(jīng)寫了，但里面還有一些小錯誤）

    如果這樣的測試還沒有，或者測試不能蓋住這種錯誤，我們寫一個新的測試來蓋住這種錯誤。

    現(xiàn)在 我們深信，程序在新的測試中不會通過。

    修復(fù)程序中的bug。

    再運行測試

    確定程序在測試中通過了。

    當(dāng)然，可能出現(xiàn)各種各樣的處理， 但思想必須很明確：你只需糾正那些被測試找出那些錯誤。

    現(xiàn)在，讓我們告訴你一個開發(fā)人員怎樣解決這種情形。 通過存在的功能性的測試

   我利用一些集成的開發(fā)環(huán)境（IDE）來查找 被修正那些類和方法的放在什么地方。

    制造一個已知的錯誤環(huán)境，來查找那些代碼判斷存在錯誤。

    后但不是不重要的，寫好測試并且放到一個現(xiàn)有的測試類中去。 如果你不小心出了錯誤， 期望你和你的同事能注意到副本，并且糾正它。