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

    TDD的主要條款：

    在任何代碼片段之前，必須先寫(xiě)好自動(dòng)檢測(cè)這段代碼功能的程序。既然代碼不存在，那么測(cè)試在一開(kāi)始失敗。

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

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

    這里有幾種我們需要考慮的測(cè)試

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

    比如測(cè)試環(huán)境里面沒(méi)有真實(shí)Datebase，需要MOCK Object）

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

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

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

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

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

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

    如果這樣的測(cè)試還沒(méi)有，或者測(cè)試不能蓋住這種錯(cuò)誤，我們寫(xiě)一個(gè)新的測(cè)試來(lái)蓋住這種錯(cuò)誤。

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

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

    再運(yùn)行測(cè)試

    確定程序在測(cè)試中通過(guò)了。

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

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

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

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

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