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