近開始接觸JBOSS IDE，想借此學(xué)習(xí)J2EE，在查資料時，偶爾接觸到j(luò)boss社區(qū)的一個開源項目——JRUnit，是Junit的一個擴展，貌似功能還挺強大的。百度一下，發(fā)現(xiàn)相關(guān)資料少之又少，遂冒出翻譯他的官方文檔的念頭，起碼也是對開源的一丁點貢獻(xiàn)，還能練練E文
首先給出這份官方資料的URL，是一個入門指南
http://labs.jboss.com/jrunit/downloads/jboss-jrunit.pdf
第一次翻譯，加上我以前也沒接觸過JRUnit，肯定會有不少錯誤，希望大家諒解指正，為了方便敘述很多地方不是完全按原文翻譯，好還是看官方的原文。我不確定的地方會加以注明并附上原文
OK，Let's get starting

原文共四章，很短總共十六頁
第一章   《概述，什么是JRUnit》
jrunit通過向基于junit的測試框架加入對基準(zhǔn)（benchmark）的支持，以及對junit框架本身的擴展，從而為基于分布式的客戶端/服務(wù)器模式的（client/server）測試提供支持。需要強調(diào)的是，jrunit不是用來替代junit的，而是對junit的一個擴展，使其對企業(yè)應(yīng)用方面有更好的支持。
說到基于C/S的測試，junit本身有著不少明顯的局限性，使它在這方面不是很好用。一個顯著的地方是，junit被設(shè)計成所有的test都在一個單獨的類、一個單獨的進(jìn)程內(nèi)運行。另一個局限是，所有的測試都是原子的、與任何外圍代碼都沒有關(guān)系，因此每個測試的生命周期都是相互獨立的。這些特征對于低級別的代碼單元很好用，但換上C/S模式的測試時則不盡然
由于C/S架構(gòu)代碼的特殊性，它們對于測試有著額外的要求。首先是對客戶端和服務(wù)器端測試的生命周期，或者說狀態(tài)，必須能進(jìn)行管理。這一點很重要，因為在客戶端進(jìn)行測試并且連接服務(wù)器之前，服務(wù)器必須已經(jīng)創(chuàng)建并初始化完畢；同樣服務(wù)器不能在客戶端完成所有測試之前關(guān)閉。此外還必須能夠?qū)⒎��?wù)器和客戶端的所有測試結(jié)果整合成為一份單一的結(jié)果格式。后，所有這些都能夠從單點驅(qū)動，這樣能夠在一次構(gòu)建中，把它們包含進(jìn)自動化測試中去。（Finally， need to be able to have all this driven  fromasinglepointsocanbeincludedwithinanautomatedtestrunfromabuild.）

jrunit通過允許多個test case以及客戶端和服務(wù)器，在多個不同的進(jìn)程上同步運行但是由一個中央driver進(jìn)行控制，來解決上述問題。這個driver控制所有test case的整個生命周期。所有由driver產(chǎn)生的test case都被放入一個harness中，由harness向driver匯報執(zhí)行情況。而這個driver本身是一個TestCase類，所以可以直接從IDE或者JUNIT中調(diào)用

jrunit還提供額外的benchmark插入（hook）到測試代碼中。這些benchmark hook能讓jrunit框架收集統(tǒng)計數(shù)據(jù)，即關(guān)于不同測試代碼段運行所花費的時間的統(tǒng)計。這些數(shù)據(jù)可以被記錄在許多持久性存儲中（a number of persistent store）并實時查看；或者也可以記錄一段時間內(nèi)的數(shù)據(jù)，來看看一段時期內(nèi)隨著代碼的變更，性能是如何受到影響的。

第一章翻譯完了，區(qū)區(qū)一頁紙搞了半天，看來翻譯比起自己看懂要難多了。水平粗糙各位見諒

C/S測試
       首先要解決的是服務(wù)器端測試的生命周期問題，因為它需要從junit生命周期管理的默認(rèn)行為中分離出來（單獨討論）
       首先需要有一種方法來通知服務(wù)器端啟動和初始化，可以用setup方法做到。一旦這個方法返回，也可以假設(shè)服務(wù)器已經(jīng)作好接收調(diào)用的準(zhǔn)備了。其次，需要告之服務(wù)器進(jìn)行關(guān)閉和清理回收資源，可以用tearDown方法來實現(xiàn)，只有在所有客戶端都已經(jīng)完成對服務(wù)器端的調(diào)用時，才能使用tearDown方法
       通過繼承org.jboss.jrunit.ServerTestCase類而不是以往的junit.framework.TestCase類，可以實現(xiàn)上述行為。這個ServerTestCase類實際上繼承自TestCase類，不過重寫了其中一些方法來實現(xiàn)所需功能
       正如在junit測試過程中一樣，server的實現(xiàn)還需要有一個test方法，用于在setUp后調(diào)用。test方法中含有assert（斷言），用于驗證服務(wù)器端數(shù)據(jù)和metrics（度量？）
       這里有幾個重點....服務(wù)器的test case只能有一個test方法，這是因為junit每運行一個test方法，會新建一個測試實例來專門運行這個test方法，因此如果有多個test方法，會有多個服務(wù)器test case的實例。如果非要改變這一機制，得對junit本身進(jìn)行相當(dāng)大的改動，所以請你只使用一個test方法（或者你也可以自己去修改junit）
       還有很重要的一點是，tearDown方法可能會在某個方法還在運行期間被調(diào)用了。你可以故意這么做，讓一個test方法一直循環(huán)直到tearDown被調(diào)用為止。舉個例子，可以像這樣：
...
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一樣）