使用MockEJB簡化EJB測試

Enterprise JavaBean (EJB)是J2EE應用程式中的重要構件塊，它為開發人員提供了一個支援服務定義、事件驅動處理和對象-關係持久性的標準架構。但是，使用EJB的開發 人員經常抱怨，EJB的使用使得應用程式的單元測試變得愈加複雜了。EJB依賴於容器的服務來運行，但是在對bean進行單元測試前將其部署到容器會減慢 這個過程，並使調試更為複雜。而最近測試驅動開發的流行又使這個問題加劇，這主要是由於其編寫測試、編寫生產代碼以及這種方法所包含的重構所組成的快速周 期。

　　本文介紹了一種架構，MockEJB，它通過允許在EJB容器內部或正式發行前小眾測試EJB，從而為EJB的測試問題提供了一種可能的解決方案。構建於 現有的模仿對象(mock object)技術上的MockEJB允許開發人員在將EJB部署到容器進行整合測試之前，像對（EJB容器外的）普通Java對象那樣，對EJB進行開 發和單元測試。在容器中，您可以使用MockEJB，通過控制bean的環境並允許類比意外條件來對EJB進行充分測試。MockEJB的使用既使開發人 員的生活變得輕鬆，又使他們的生產力更高，還有助於實現比通常情況下更全面的測試覆蓋範圍。

EJB測試面臨的挑戰
　　Enterprise JavaBean (EJB)是許多大型J2EE應用程式中的重要構件塊，它還被用於定義打包服務及其介面（使用會話bean）、建立事件處理常式（使用訊息驅動 bean），有時候還用來提供持久性機制（通過實體bean）。EJB的許多功能和優點來自於EJB容器所提供的標準化的運行時環境和服務，包括自動化的 線程和記憶體管理、交易管理以及聲明式安全性。但是，因為對容器的依賴性，EJB不能在容器外運行，所以當對EJB組件進行單元測試時，這個強大的運行時環 境也存在一些問題。我們如何能夠輕鬆地對由一個應用伺服器所提供的、運行在EJB容器內的東西進行單元測試呢？

　　針對EJB的測試問題，人們提出了很多方法，從支援基本的容器外單元測試的簡單EJB基類，到複雜的測試架構，比如Cactus（參見補充閱讀一節），從而使得對運行在容器內的EJB進行單元測試成為可能。最近，作為對環境需求複雜的代碼進行單元測試的一個可選方案，又出現了“模仿對象”方法，而MockEJB正是這種思想的特定於EJB開發的實現。

測試驅動開發和模仿對象
　　在介紹MockEJB的細節之前，有必要先說明一下為它提供基礎的思想和技術。

　　測試驅動開發(TDD)是一種軟體開發（而不是測試）方法，它將單元測試置於過程的中心地位。與編寫大量代碼、然後在允許的時間範圍內進行儘可能多的單元測試的傳統方式不同，TDD完全顛覆了這個過程，它只為實現成功的測試而編寫代碼。其過程是高度可迭代的，包括一個快速周期：編寫測試，然後編寫 使測試成功所需的代碼，最後重構以改進設計——如果新代碼顯示設計還不是最優的話。TDD的基本規則是，編寫儘可能多的測試，所有的單元測試都是自動進行的，所有的測試都必須始終可以通過。補充閱讀一節有TDD更多相關資訊的連結。

　　雖然其思想非常簡單，但是人們發現，在實踐中TDD令人難以置信地有效。因為不斷增長的單元測試集會對編寫的代碼提供直接的反饋和驗證，所以隱 患不會累積起來而在開發過程的後期引發問題。TDD的另一個優點是，它會產生一個可靠的大型單元測試集，這意味著開發人員可以在離開代碼（或者實際上是采 用了另一個開發人員的代碼）一段時間後，再返回到代碼，並安全地對其變更，因為如果在更改中有錯誤出現，單元測試就會失敗。

　　要實現有效TDD過程，開發人員所使用的開發環境需要允許他們針對一個不斷變化的代碼基址快速編寫和執行測試。從EJB開發人員的角度來看， 問題在於，允許EJB在容器中啟動並執行部署過程會極大地減慢編譯過程，並使開發環境變得更為複雜。這將會導致下面的危險情況：EJB開發人員不得不“批處 理”他們的測試，並不再經常對代碼運行大型單元測試集。雖然仍然進行單元測試，但是這樣就降低了TDD方法所引以為傲的快速反饋速度。因此，為了更有效地 支援TDD，我們希望能夠消除開發時的EJB部署周期；使用“模仿”EJB容器就是一種實現方法。

　　使用TDD開發複雜系統的另一個挑戰是，很難將要測試的功能與系統的其他部分隔開。應用程式組件（通常被打包為會話bean）一般要依賴於其他 的組件來向其提供服務。在單元測試環境中，我們希望能消除要測試的組件的依賴性，以便調用的服務返回可預測的測試資料，而不是運行實際的生產代碼。對（由 實體bean所表示的）持久性資料的依賴性是這一問題的另一體現。最好可以以一種不依賴於資料庫的方式進行單元測試（即使在開發環境中，資料庫也通常是共 享資源，因此難以控制）。

　　模仿對象（或“mocks”）技術有助於將複雜或難以控制的運行時組件替換為能產生快速單元測試過程的輕量級可控版本。模仿對象的理念是，允許 單元測試用一個專門編寫的替代品替換掉正常運行時環境中的部分，替代品實現與正常組件相同的介面，但是更容易為單元測試代碼所控制。模仿對象的實現存在於 java.sql JDBC類、java.io IO庫、java.net連網庫和其它許多標準的Java運行時環境組件中。這些模仿實現使我們可以類比錯誤，可以測試資料庫代碼而無需真的有一個資料 庫，測試網路代碼而無需有一個真正的伺服器（或客戶機），等等。總而言之，模仿對象使得對需要複雜運行時環境的代碼的單元測試過程更容易處理。 MockEJB是模仿對象領域新近出現的架構，它提供了許多重要的J2EE介面的模仿實現。

MockEJB簡介
　　MockEJB是Alexander Ananiev所編寫的一個EJB測試架構。它結合了許多現有的思想和技術，為EJB開發人員提供了一個強大的測試架構，使他們可以輕鬆地對EJB進行單 元測試，不管是在EJB容器內部還是外部。實質上，MockEJB提供了EJB所需的所有重要J2EE介面的模仿對象實現，因此為開發人員提供了一個在單 元測試中可以輕鬆控制的模仿容器實現。它所提供的模仿容器是一個普通Java對象，而且它允許像對普通Java對象那樣在J2EE應用伺服器的傳統容器外 對EJB進行測試。此外，MockEJB也與Cactus伺服器端測試架構進行了整合，為需要的EJB開發人員提供了一個應用伺服器內的單元測試環境。

　　本文重點介紹使用MockEJB在應用伺服器外測試bean。對於這種使用方式，MockEJB提供的重要特性包括：

• 實現介面、調用bean類的EJBObject的自動產生。
• bean環境的自動設定，包括容器事務、EJBContext對象和EJBMetaData。
• 一個記憶體中的JNDI提供者，它允許綁定和尋找容器資源。
• 對其他EJB操作的調用。
• 對CMP和BMP實體bean的支援。
• 一個記憶體中的JMS提供者，它允許發送和接收JMS訊息。
• 圍繞bean添加攔截器以便允許對測試環境進行控制和監視的能力。

　　MockEJB是作為一個Java庫提供的，同時提供的還有一些說明其用法的樣本和javadoc文檔。像大多數庫一樣，要掌握MockEJB，最容易的方法就是使用它來解決一些簡單的問題，所以接下來，我們將看看如何使用MockEJB來測試一些會話bean。

使用MockEJB
　　為了說明MockEJB的使用，我們開發了一個非常簡單的應用程式，它包含兩個會話bean和一個MDB。 本文附帶的zip檔案包含了一個簡單的codeline，其中包含要測試的bean的原始碼、單元測試原始碼和一個構建和測試bean的Ant build指令碼。要構建代碼並運行測試，需要安裝Ant、Junit和MockEJB，還有JDK。在codeline的README檔案中可以找到使用 範例程式碼的詳細說明。

　　所提供的EJB是為了研究MockEJB的一些特定功能而開發的，它們非常簡單，通過各種服務介面提供了一個基本的計算機。有3個bean：

• SimpleCalc，最簡單的bean，它是一個無狀態會話bean，提供了一個為double運算元提供加、減、乘、除服務的介面。該bean會使您瞭解MockEJB對簡單EJB測試的支援。
• ParsingCalc， 也是一個無狀態會話bean，它只提供了一個calculate(字串運算式)操作。該bean分析傳給它的字串運算式，抽取出所要求的操作的運算子 和運算元，並調用SimpleCalc bean執行計算。該bean會使您瞭解MockEJB對bean間引用的支援。
• MessageCalc， 一個訊息驅動bean，它通過JMS隊列監聽訊息，抽取任何接收到的簡訊的主體，並使用ParsingCalc bean對其進行分析，將計算的結果返回給請求訊息的JMSReplyTo目的站。該bean會使您瞭解MockEJB對JMS和MDB的支援。

　　使用MockEJB測試bean的一般過程如下：

• 調用MockEJB，以便將其安裝為當前環境的預設JNDI提供者（只需調用靜態方法MockContextFactory.setAsInitial()）。
• 建立一個JNDI上下文，並模仿與其關聯的EJB容器執行個體（只需建立InitialContext和MockContainer的執行個體）。
• 可選地，建立bean所需的任何模仿J2EE環境對象（例如，JMS工廠和目的站），並將它們安裝到JNDI目錄下（例如，通過從com.mockejb.jms包建立對象並調用context.rebind()，將它們與模仿JNDI目錄下的名稱關聯）。
• 為bean建立部署描述符，以便向架構描述它們。MockEJB部署描述符是Java對象而不是XML文檔，而且是由適當類（比如SessionBeanDescriptor）的構造對象建立的，建構函式參數定義了介面和要部署的bean執行個體。
• 最後，模仿容器的deploy()方法可以對所有的部署描述符對象進行調用，以便部署bean並使它們可以進行測試。

　　這個簡單的過程一完成，就可以通過您所熟悉的標準J2EE尋找/收縮/調用過程來訪問bean了。

測試簡單EJB
　　為了說明這個過程，我們從可能的最簡單的例子入手，來瞭解MockEJB如何讓我們在容器外測試簡單的獨立會話bean。下面的程式碼片段顯示了bean是如何部署到本地記憶體中的容器中進行測試的：

// Setup the JNDI environment to use the MockEJB 
// context factory
MockContextFactory.setAsInitial();

// Create the initial context that will be used for binding EJBs
Context ctx = new InitialContext();

// Create an instance of the MockContainer
MockContainer mc = new MockContainer(ctx);

// Create deployment descriptor for our sample bean
// This is used instead of an XML descriptor
SessionBeanDescriptor dd = new SessionBeanDescriptor(
   "java:comp/env/ejb/SimpleCalc", 
   SimpleCalcHome.class, SimpleCalc.class,
   new SimpleCalcBean()) ;

// Deploy our bean to the container allowing it to
// be found via JNDI and tested
mc.deploy(dd);

　　這段代碼設定了使用MockEJB的模仿JNDI實現的環境，而不是基於容器的環境，建立了一個模仿EJB容器來部署bean，然後通過 SessionBeanDescriptor對象來描述bean，將其部署到容器。這種將Java對象作為bean部署描述符的用法，是MockEJB的 容器與真正的應用伺服器EJB容器的主要區別。從代碼中可以看出，為bean建立描述符非常簡單，只需通過指定它要綁定的JNDI名稱、提供本地和遠程接 口定義的類以及要部署的bean類執行個體的方式來構造它。

　　bean部署到模仿容器上之後，就可以編寫針對它的測試了，就像它是部署到常規的應用伺服器容器上一樣。下面的Junit測試方法顯示了調用樣本bean的相關方法所需的代碼：

public void testTwoPlusTwo() throws Exception
{
    // Look up the home
    Context ctx = new InitialContext();
    Object ejbObj = 
        ctx.lookup("java:comp/env/ejb/SimpleCalc");

    // Narrowing is not needed with MockEJB or WebLogic, but 
    // we call it anyway for standardization
    SimpleCalcHome home = (SimpleCalcHome)
       PortableRemoteObject.
          narrow(ejbObj, SimpleCalcHome.class);
    SimpleCalc calc = home.create();
    assertEquals("Add operator failure", 4.0, 
                  calc.add(2.0, 2.0), 0.0) ;
}

　　可以看出，如果在一個應用伺服器容器中運行，該代碼就與調用bean操作所需的代碼相同，所以一旦測試bean已經部署，就不需要特定於 MockEJB的編程了。在本文附帶的範例程式碼中，TestSimpleCalcBean Junit測試案例類包含了測試SimpleCalc bean的例子代碼。但是，要注意，執行特定於MockEJB的容器初始化和bean部署的代碼已經從Junit測試案例類被重構為一個稱為 MockBeanTestBase的抽象基類。該類可以提供其他的特性（比如，在EJB容器內運行），並可避免測試之間的代碼重複。

測試引用其他EJB的EJB
　　前面的例子明顯過於簡單了，因為bean本身沒有使用駐留在容器內的資源，所以我們只需執行個體化bean類的對象並調用其方法也能達到相同的效果。我們 來看看MockEJB如何協助我們測試引用其他bean的會話bean。在我們的例子代碼中有一個ParsingCalc bean，它需要SimpleCalc bean的服務來執行計算。

　　通過將所需的所有bean部署到模仿容器上，並關聯正確的JNDI名稱，MockEJB使EJB相互之間可以輕鬆地進行尋找和引用。對應的範例程式碼可在TestParsingCalcBean Junit類中找到。初始化的關鍵區段顯示在下面的程式碼片段中：

// Initialize initial context and container here
// ...

// Create deployment descriptor for the bean under
// test.
SessionBeanDescriptor testDD = 
   new SessionBeanDescriptor(
      "java:comp/env/ejb/ParsingCalc", 
      ParsingCalcHome.class, ParsingCalc.class,
      new ParsingCalcBean()) ;
// Create deployment descriptor for the bean that 
// the bean under test relies upon.
SessionBeanDescriptor depDD = 
   new SessionBeanDescriptor(
      "java:comp/env/ejb/SimpleCalc", 
      SimpleCalcHome.class, SimpleCalc.class,
      new SimpleCalcBean()) ;
// Deploy both beans to the mock container
mc.deploy(depDD) ;
mc.deploy(testDD);

　　（注意，在所提供的範例程式碼中，bean部署實際上是使用來自Junit測試類別擴充後的抽象基類的deployRemoteSessionBean()方法實現的。在上面的程式碼片段中我們將所需的過程展示得非常清楚。）

　　現在，兩個bean都部署到模仿容器上了，而且如果SimpleCalc所綁定的JNDI名稱（在上面的例子中是java: comp/env/ejb/SimpleCalc）與ParsingCalc bean在其初始上下文中所尋找的名稱匹配，MockEJB就會返回一個到正確的EJB對象的引用。在例子單元測試類的 testParsingCalcOperations方法中，可以找到一些ParsingCalc bean的樣本單元測試代碼，其中bean是使用常規的EJB調用進行測試的。如果運行測試，ParsingCalc bean就會成功定位並調用對SimpleCalc bean的操作。

　　這個例子說明了MockEJB的最簡單的用途，但是MockEJB還提供了一個非常有用的功能，即，在容器外開發、測試和偵錯工作階段bean的能力。同樣，我們也不打算利用EJB容器所提供的任何更為複雜的功能。

測試MDB
　　 現在我們來考慮如何利用MockEJB的JMS功能在容器外測試MDB。顯然，測試MDB與測試會話bean（或實體bean）截然不同，因為bean只 能通過向其正在監聽的適當JMS主題或隊列發送訊息而使用。因此，雖然仍然需要部署bean本身，但是設定MDB以進行測試的大部分工作都與建立JMS對 象並將bean串連到正確的目的站有關。幸運的是，MockEJB使得在短短几行代碼中實現所有這些任務成為可能。下面的程式碼片段說明了如何設定環境以便 測試MDB：

// Initialize initial context and container
MockContextFactory.setAsInitial();
Context ctx = new InitialContext();
MockContainer mc = new MockContainer(ctx);

String factoryName = "jms/QueueConnectionFactory" ;
String requestQueueName  = "jms/queue/CalcRequestQueue" ;
String responseQueueName = "jms/queue/CalcResponseQueue" ;

// Create the mock JMS objects and bind them to
// the appropriate names in the mock JNDI directory
QueueConnectionFactory qcf =
   new QueueConnectionFactoryImpl() ;
ctx.rebind(factoryName, qcf);
Queue queue = new MockQueue(requestQueueName) ;
ctx.rebind(requestQueueName, this.queue);

ctx.rebind(responseQueueName, 
   new MockQueue(responseQueueName));
 // Create an instance of the bean under test and
// attach it to the test queue as a listener
MessageCalcBean beanObj = new MessageCalcBean() ;       
((MockQueue)queue).addMessageListener(beanObj) ;

// Create a deployment descriptor for the MDB
// and set the flag indicating that the JMS
// objects are already created and bound to the
// specified names
MDBDescriptor mdbDD = new MDBDescriptor(
   factoryName, requestQueueName, beanObj) ;
mdbDD.setIsAlreadyBound(true) ;

// Deploy the MDB ready for testing
this.container.deploy(mdbDD);

　　從程式碼片段中可以看出，設定bean的大部分代碼都牽涉到建立適當的JMS模仿對象並將其綁定到模仿JNDI目錄中所要求的名稱。現在，當 MDB尋找隊列串連工廠時，就會被傳遞一個到上面所建立的模仿工廠的引用；類似地，當它請求CalcRequestQueue時，就會被傳遞一個到模仿隊 列的引用，允許我們在需要時操縱和監視隊列。對應於此過程的例子代碼可在MockBeanTestBase類的 deployQueueMessageDrivenBean()方法中找到。

　　現在我們可以通過建立適當的（模仿）JMS訊息來發送它，並通過模仿隊列將其指派給bean，來對MDB進行測試。相應的程式碼片段如下：

// ... following from previous code fragment

// Provide us with access to the queues
QueueConnection conn = qcf.createQueueConnection();
QueueSession sess = conn.createQueueSession( false, 
                           Session.AUTO_ACKNOWLEDGE);
 // Create our test message
TextMessage reqMsg = session.createTextMessage();

// Look up the reply queue and set in the message
Queue replyQ = (Queue)ctx.lookup(RESPONSE_QUEUE_NAME) ;
reqMsg.setJMSReplyTo(replyQ) ;

// Start the connection and create a receiver to 
// to begin receiving messages
conn.start();
QueueReceiver recv = sess.createReceiver(replyQ) ;
 // Get rid of any messages that might be on the 
// response queue because of failed tests
while(recv.receiveNoWait()!=null) ;

// Send a message to run a unit test
reqMsg.setText("2.0 + 2.0") ;
sender.send(reqMsg);
TextMessage reply1 = 
  (TextMessage)recv.receive(RECEIVE_TIMEOUT_SEC) ;
assertNotNull(reply1);
assertEquals("Wrong addition result", 
    "2.0 + 2.0 = 4.0", reply1.getText()) ;

　　在測試代碼中，我們可以使用標準的JMS API來尋找隊列和串連工廠，並建立、發送和接收訊息。因為我們使用了模仿隊列實現，MockEJB的JMS實現會處理我們發送給請求隊列的訊息，調用 MDB的onMessage()方法。這會阻塞直到onMessage()方法返回，所以我們可以立即檢查響應。MockEJB的JMS實現的阻塞（同 步）特性非常有利於單元測試，因為它允許我們測試JMS驅動的操作的結果，而無需處理單元測試代碼中無法預測的延遲和逾時。它還允許我們對會話bean和 MDB串連在一起的地方進行整合測試。

　　除了標準的JMS API的實現外，MockEJB還提供了各種方便的方法來發送訊息並檢查隊列的內容，而無需求助於有時會很麻煩的JMS API。在本例中，我們沒有使用這些方法，因為這種方法有一個缺點，即，當在一個真正的EJB容器內運行EJB時，測試不能重用，而本文所提供的範例程式碼 則在兩種模式下都可以運行單元測試。

　　總結一下，在幾段短小的代碼片斷中，我們使用MockEJB將會話bean和MDB部署到一個本地記憶體中的容器，將bean綁定到JNDI目 錄，以便允許它們互相調用，並使用MockEJB的記憶體中的JMS提供者測試了一個MDB，而無需在容器中配置真正的JMS提供者。遺憾的是，在這篇 短小的文章內，無法再展示更多的MockEJB特性，但是我們希望您已經看到了該架構支援有效測試驅動EJB開發的潛力。

MockEJB的其他特性
　　雖然不能示範MockEJB的所有特性，但是還是可以簡要地探討一下這個功能豐富的架構的其他還未討論的特性。測試實體bean

　　除了提供許多測試會話bean和訊息驅動bean的方便功能外，MockEJB也為在容器外測試BMP和CMP實體bean提供了許多方便功 能。模仿容器提供了一個記憶體中的實體bean資料庫，允許用測試資料來填充它以提供沒有資料庫的可預測測試。對BMP實體bean的處理方式類似於會話 bean，因為出現了bean實現，雖然該實現是在運行時為CMP實體bean產生的。MockEJB還提供了自己的方面實現（此處是AOP術語），允許 安裝方面以便提供特定的finder和容器管理關聯性(Container-Managed Relationship，CMR)行為。

使用MockRunner的事務和JDBC
　　如果需要測試交叉bean的事務性行為，MockEJB可以與MockRunner的J2EE UserTransaction介面的MockUserTransaction實現一起使用。模仿使用者事務的執行個體可以綁定到MockEJB的模仿JNDI 目錄的javax.transaction.UserTransaction名稱下，然後就可以操縱和監視該事務對象以檢查行為的正確性。類似地， MockRunner的JDBC實現可在MockEJB內使用，以便提供一個模仿資料來源，該資料來源提供標準的測試資料，而且要測試的代碼可以監視其使用的 正確性。

AOP和攔截器
　　 如上所述，MockEJB提供了一個簡單的AOP架構，它允許我們在EJB處理生命週期中的任何點插入代碼。MockEJB中的方面被定義為攔截器和切入點的 組合，其中攔截器指定將會在調用目標方法之前以及之後啟動並執行邏輯（即AOP術語中的“環繞通知”），而切入點定義要截取的方法的集合。所提供的實現非常強 大且靈活，允許在架構（或者bean或測試代碼）中的任何方法調用時引入攔截器，允許監視測試（如：檢查方法是否被調用）或插入資料（如：從BMP finder方法返回一個主鍵列表）。

　　實際上，AOP為模仿對象方法提供了一種強大的可選方案，因為攔截器允許您改變目標類的單個方法的行為，而不是必須將整個類作為一個模仿對象 重新實現。對於MockEJB，這兩種方法可以互換。例如，您可以建立整個會話bean的模仿版本（例如，使用EasyMock架構），或者只截取並更改 bean中選定的方法。

在容器中使用MockEJB
　　最後，有一個MockEJB的特性我們曾提到過，但沒有詳細介紹，就是在常規的EJB容器內使用的能力。MockEJB的這種用法可以為bean提供 一個容易控制的運行時封裝器，因此允許類比在常規的單元測試中難以建立的條件，從而使在容器內進行的EJB單元測試更為簡單。

　　雖然在容器外運行EJB允許您使用TDD方法開發代碼，但是它並不能完全取代容器內測試。MockEJB不支援基於XML的部署描述符（更不 用說特定於供應商的描述符和設定檔了），所以將EJB部署到容器中並運行單元測試是驗證其正確性的重要組成部分。使用MockEJB時，開發人員大部分 的開發工作都可以依賴於容器外模式，運行容器內測試就不那麼頻繁了——例如，在向版本控制系統提交更改之前。

　　為了實現容器內支援，MockEJB提供了一個對Cactus ServletTestCase類的擴充，稱為OptionalCactusTestCase，它允許在伺服器端的Cactus下或者使用MockEJB 的容器在伺服器外運行測試案例子類中的測試。如果要在伺服器的Cactus下運行測試，則通過將系統屬性mockejb.cactus.mode設定為 true來控制類的行為。在運行時，如果需要的話，測試可以調用isRunningOnServer()方法在兩種模式之間改變行為。容器內模式可以靈活 地將容器和模仿所提供的資源進行混合和匹配。這是由MockEJB的JNDI上下文完成的，需要時也可以委託給容器的上下文。因此，可以依賴模仿EJB來 控制測試的邊界，而其他資源（比如JMS和資料來源）可以由容器來提供，以便使測試更為逼真。

　　本文附帶的範例程式碼允許在EJB容器內或容器外對bean運行所提供的單元測試，因此可以視為在容器內使用MockEJB的例子。

下載
　　MockEJbSamples.zip包含了本文的範例程式碼。

結束語
　　在本文中，我們揭示了一些在TDD方法的快速開發/測試/重構周期中進行EJB測試所產生的問題，並引入了一種測試架構，MockEJB。通過提供一個支援記憶體中EJB測試的輕量級模仿EJB容器，該架構可以協助解決這些問題。

　　我們看到，藉助於比較少的代碼（其中大部分都可以放在可重用的基類中），就可以將會話bean或MDB部署到模仿容器中，並在本地對其進行測試，而無需配置和使用完全的J2EE應用伺服器。

　　此外，MockEJB還提供了其它許多有用的功能，包括測試實體bean的能力，對一旦完成初始開發就可以在容器內啟動並執行支援（提供對bean 的運行時環境的方便控制），對JDBC和J2EE事務的支援（通過Mock Runner），以及一個靈活而強大的基於方面的攔截器實現，它允許對測試環境進行控制和監視。

　　我們鼓勵您在項目中使用MockEJB，體驗它所提供的流線化的單元測試過程，尤其是您打算對EJB組件使用測試驅動開發時。

補充閱讀

• Apache Ant——範例程式碼所使用的構建工具
• Jakarta Cactus——一個容器內J2EE單元測試架構
• EasyMock——使用Java的代理機制動態產生模仿對象的架構
• MockEJB——MockEJB架構首頁
• MockObjects.com——該網站集中了許多與進行單元測試的模仿對象方法相關的資訊
• MockRunner——也是一個J2EE模仿對象架構，在MockEJB內部使用，提供JDBC、JMS和Struts模仿對象實現
• TestDriven.com——一個測試驅動開發的公用資源頁面
• Test Driven Development——對於測試驅動開發方法的最早描述之一，Object Mentor撰寫

dev2dev EJBTechnologyCenter

原文出處:http://dev2dev.bea.com/pub/a/2005/10/mock_ejbs.html

作者簡介
	Alexander Ananiev擁有超過16年的使用各種語言和技術設計和開發電腦系統的經驗。目前他在一家大型諮詢公司擔任架構師。
	Eoin Woods已經在企業IT領域工作了15年，目前他在一家總部設在倫敦的全球投資銀行中擔任架構師。他一直在使用BEA的產品，從Tuxedo版本4開始。