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