/*如果連接池中的緩存連接數(shù)大于少緩存連接數(shù)，檢查釋放數(shù)據(jù)連接后是否
緩存連接數(shù)比之前減少了一個，反之緩存連接數(shù)是否保持為少緩存連接數(shù)
*/
if (cacheSize > minConnections){
assertEquals(cacheSize， cacheSizeAfter + 1);
} else {
assertEquals(cacheSize， minConnections);
}
}
/** 釋放建立測試起始環(huán)境時的資源。
*/
protected void tearDown() {
cacheImpl = null;
conProxy.destroy();
}
public DefaultConnectionProxyTest(String name) {
super(name);
}
/** 你可以簡單的運(yùn)行這個類從而對類中所包含的測試單元進(jìn)行測試。
*/
public static void main(String args[]) {
junit.textui.TestRunner.run(DefaultConnectionProxyTest.class);
}
}
當(dāng)單元測試完成后，我們可以用Junit提供的TestSuite對象對測試單元進(jìn)行組織，你可以決定測試的順序，然后運(yùn)行你的測試。
4. 如何維護(hù)單元測試
通過上面的描述，我們對如何確定和編寫測試有了基本的了解，但是需求總是變化的，因此我們的單元測試也會根據(jù)需求的變化不斷的演變。如果我們決定修改類的行為規(guī)則，可以明確的是，我們當(dāng)然會對針對這個類的測試單元進(jìn)行修改，以適應(yīng)變化。但是如果對這個類僅有調(diào)用關(guān)系的類的行為定義沒有變化則相應(yīng)的單元測試仍然是可靠和充分的，同時如果包含行為變化的類的對象的狀態(tài)定義與其沒有直接的關(guān)系，測試單元仍然起效。這種結(jié)果也是封裝原則的優(yōu)勢體現(xiàn)。
關(guān)于作者
申文波： 1973年出生，現(xiàn)于艾昂科技上海公司任技術(shù)顧問。在關(guān)系數(shù)據(jù)庫對象建模方面有較長的工作經(jīng)驗，熟悉Java語言，目前從事的工作領(lǐng)域主要包括OOA、OOD和企業(yè)應(yīng)用。您可以通過郵件alair_china@yahoo.com.cn與他聯(lián)系。
--------------------------------------------------------------------------------
JUnit 是一個集成測試工具。能實現(xiàn)測試的自動化。
他寫的是單元測試：軟件工程里的白盒測試，是測試某個類的某個方法的功能。
XP 中推崇的 test first design 是基于以上的技術(shù)
如果你要寫一段代碼：
先用 junit 寫測試，然后再寫代碼
寫完代碼，運(yùn)行測試，測試失敗
修改代碼，運(yùn)行測試，直到測試成功
如果以后對程序進(jìn)行修改，優(yōu)化 ( refactoring )，只要再運(yùn)行測試代碼
如果所有的測試都成功，則代碼修改完成。
Java 下的 team 開發(fā)，一般采用 cvs(版本控制) + ant(項目管理) + junit(集成測試) 的模式：
每天早上上班，每個開發(fā)人員從 cvs server 獲取一個整個項目的工作拷貝。
拿到自己的任務(wù)，先用 junit 寫的任務(wù)的測試代碼。
然后寫任務(wù)的代碼，運(yùn)行測試，直到測試通過，任務(wù)完成
在下班前一兩個小時，各個開發(fā)人員把任務(wù)提交到 cvs server
然后由主管對整個項目運(yùn)行自動測試，哪個測試出錯，找相關(guān)人員修改，直到所有測試通過。下班。。。
先寫測試，再寫代碼的好處：
從技術(shù)上強(qiáng)制你先考慮一個類的功能，也是這個類提供給外部的接口，而不至于太早
陷入它的細(xì)節(jié)。這是面向?qū)ο筇岢囊环N設(shè)計原則。
好的測試其實是一個好的文檔，這個類使用者往往可以通過查看這個類的測試代碼了
解它的功能。特別的，如果你拿到別人的一個程序，對他寫測試是好的了解這個程序
的功能的方法。 xp的原則是 make it simple，不是很推薦另外寫文檔，因為項目在開
發(fā)過程中往往處于變動中，如果在早期寫文檔，以后代碼變動后還得同步文檔，多了一
個工作，而且由于項目時間緊往往文檔寫的不全或與代碼不一致，與其這樣，不如不寫。
而如果在項目結(jié)束后再寫文檔，開發(fā)人員往往已經(jīng)忘記當(dāng)時寫代碼時的種種考慮，況且
有下一個項目的壓力，管理人員也不愿意再為舊的項目寫文檔。導(dǎo)致以后維護(hù)的問題。
沒有人能保證需求不變動，以往項目往往對需求的變動大為頭疼，害怕這個改動會帶來
其他地方的錯誤。為此，除了設(shè)計好的結(jié)構(gòu)以分割項目外（松耦合），但如果有了測試，
并已經(jīng)建立了一個好的測試框架，對于需求的變動，修改完代碼后，只要重新運(yùn)行測試
代碼，如果測試通過，也保證了修改的成功，如果測試中出現(xiàn)錯誤，也會馬上發(fā)現(xiàn)錯
在哪里。修改相應(yīng)的部分，再運(yùn)行測試，直至測試完全通過。
軟件公司里往往存在開發(fā)部門和測試部門之間的矛盾：由于開發(fā)和測試分為兩個部門，
多了一層溝通的成本和時間，溝通往往會產(chǎn)生錯誤的發(fā)生。而且極易形成一個怪圈：開
發(fā)人員為了趕任務(wù)，寫了爛爛的代碼，把它扔給測試人員，然后寫其他的任務(wù)，測試
當(dāng)然是失敗的，又把代碼拿回去重寫，而且在國內(nèi)往往一個軟件公司技術(shù)差的部門
是測試部門（好的人都跑去寫代碼了），測試成了一個很頭疼的問題。這種怪圈的根
源是責(zé)任不清，根據(jù) xp 中的規(guī)定：寫這個代碼的人必須為自己的代碼寫測試，而且只
有測試通過，才算完成這個任務(wù)（這里的測試包括所有的測試，如果測試時發(fā)現(xiàn)由于你
的程序?qū)е聞e的模塊的測試失敗，你有責(zé)任通知相關(guān)人員修改直至集成測試通過），這
樣可以避免這類問題的發(fā)生。
