近開始接觸JBOSS IDE，想借此學(xué)習(xí)J2EE，在查資料時(shí)，偶爾接觸到j(luò)boss社區(qū)的一個(gè)開源項(xiàng)目——JRUnit，是Junit的一個(gè)擴(kuò)展，貌似功能還挺強(qiáng)大的。百度一下，發(fā)現(xiàn)相關(guān)資料少之又少，遂冒出翻譯他的官方文檔的念頭，起碼也是對開源的一丁點(diǎn)貢獻(xiàn)，還能練練E文
首先給出這份官方資料的URL，是一個(gè)入門指南
http://labs.jboss.com/jrunit/downloads/jboss-jrunit.pdf
第一次翻譯，加上我以前也沒接觸過JRUnit，肯定會有不少錯(cuò)誤，希望大家諒解指正，為了方便敘述很多地方不是完全按原文翻譯，好還是看官方的原文。我不確定的地方會加以注明并附上原文
OK，Let's get starting
原文共四章，很短總共十六頁
第一章 《概述，什么是JRUnit》
jrunit通過向基于junit的測試框架加入對基準(zhǔn)（benchmark）的支持，以及對junit框架本身的擴(kuò)展，從而為基于分布式的客戶端/服務(wù)器模式的（client/server）測試提供支持。需要強(qiáng)調(diào)的是，jrunit不是用來替代junit的，而是對junit的一個(gè)擴(kuò)展，使其對企業(yè)應(yīng)用方面有更好的支持。
說到基于C/S的測試，junit本身有著不少明顯的局限性，使它在這方面不是很好用。一個(gè)顯著的地方是，junit被設(shè)計(jì)成所有的test都在一個(gè)單獨(dú)的類、一個(gè)單獨(dú)的進(jìn)程內(nèi)運(yùn)行。另一個(gè)局限是，所有的測試都是原子的、與任何外圍代碼都沒有關(guān)系，因此每個(gè)測試的生命周期都是相互獨(dú)立的。這些特征對于低級別的代碼單元很好用，但換上C/S模式的測試時(shí)則不盡然
由于C/S架構(gòu)代碼的特殊性，它們對于測試有著額外的要求。首先是對客戶端和服務(wù)器端測試的生命周期，或者說狀態(tài)，必須能進(jìn)行管理。這一點(diǎn)很重要，因?yàn)樵诳蛻舳诉M(jìn)行測試并且連接服務(wù)器之前，服務(wù)器必須已經(jīng)創(chuàng)建并初始化完畢；同樣服務(wù)器不能在客戶端完成所有測試之前關(guān)閉。此外還必須能夠?qū)⒎⻊?wù)器和客戶端的所有測試結(jié)果整合成為一份單一的結(jié)果格式。后，所有這些都能夠從單點(diǎn)驅(qū)動，這樣能夠在一次構(gòu)建中，把它們包含進(jìn)自動化測試中去。（Finally， need to be able to have all this driven fromasinglepointsocanbeincludedwithinanautomatedtestrunfromabuild.）
jrunit通過允許多個(gè)test case以及客戶端和服務(wù)器，在多個(gè)不同的進(jìn)程上同步運(yùn)行但是由一個(gè)中央driver進(jìn)行控制，來解決上述問題。這個(gè)driver控制所有test case的整個(gè)生命周期。所有由driver產(chǎn)生的test case都被放入一個(gè)harness中，由harness向driver匯報(bào)執(zhí)行情況。而這個(gè)driver本身是一個(gè)TestCase類，所以可以直接從IDE或者JUNIT中調(diào)用
jrunit還提供額外的benchmark插入（hook）到測試代碼中。這些benchmark hook能讓jrunit框架收集統(tǒng)計(jì)數(shù)據(jù)，即關(guān)于不同測試代碼段運(yùn)行所花費(fèi)的時(shí)間的統(tǒng)計(jì)。這些數(shù)據(jù)可以被記錄在許多持久性存儲中（a number of persistent store）并實(shí)時(shí)查看；或者也可以記錄一段時(shí)間內(nèi)的數(shù)據(jù)，來看看一段時(shí)期內(nèi)隨著代碼的變更，性能是如何受到影響的。
第一章翻譯完了，區(qū)區(qū)一頁紙搞了半天，看來翻譯比起自己看懂要難多了。水平粗糙各位見諒
C/S測試
首先要解決的是服務(wù)器端測試的生命周期問題，因?yàn)樗枰獜膉unit生命周期管理的默認(rèn)行為中分離出來（單獨(dú)討論）
首先需要有一種方法來通知服務(wù)器端啟動和初始化，可以用setup方法做到。一旦這個(gè)方法返回，也可以假設(shè)服務(wù)器已經(jīng)作好接收調(diào)用的準(zhǔn)備了。其次，需要告之服務(wù)器進(jìn)行關(guān)閉和清理回收資源，可以用tearDown方法來實(shí)現(xiàn)，只有在所有客戶端都已經(jīng)完成對服務(wù)器端的調(diào)用時(shí)，才能使用tearDown方法
通過繼承org.jboss.jrunit.ServerTestCase類而不是以往的junit.framework.TestCase類，可以實(shí)現(xiàn)上述行為。這個(gè)ServerTestCase類實(shí)際上繼承自TestCase類，不過重寫了其中一些方法來實(shí)現(xiàn)所需功能
正如在junit測試過程中一樣，server的實(shí)現(xiàn)還需要有一個(gè)test方法，用于在setUp后調(diào)用。test方法中含有assert（斷言），用于驗(yàn)證服務(wù)器端數(shù)據(jù)和metrics（度量？）
這里有幾個(gè)重點(diǎn)....服務(wù)器的test case只能有一個(gè)test方法，這是因?yàn)閖unit每運(yùn)行一個(gè)test方法，會新建一個(gè)測試實(shí)例來專門運(yùn)行這個(gè)test方法，因此如果有多個(gè)test方法，會有多個(gè)服務(wù)器test case的實(shí)例。如果非要改變這一機(jī)制，得對junit本身進(jìn)行相當(dāng)大的改動，所以請你只使用一個(gè)test方法（或者你也可以自己去修改junit）
還有很重要的一點(diǎn)是，tearDown方法可能會在某個(gè)方法還在運(yùn)行期間被調(diào)用了。你可以故意這么做，讓一個(gè)test方法一直循環(huán)直到tearDown被調(diào)用為止。舉個(gè)例子，可以像這樣：
...
public void testServerMetrics()
{
while(!stop)
{
// collect data here
}
}
protected void tearDown()
{
stop = true;
// so will cause testServerMetrics() to break out of loop
// do shutdown and clean up code.
}
...
對于客戶端test case來說，jrunit沒有什么特別的要求，只要繼承了junit.framework.TestCase類，確保滿足了junit test case的要求可以了。（譯注：是和以前用junit一樣）
