2012-01-03 8 views
5

Come posso testare l'unità ProcessorBean? Dato che non voglio testare il ProcessorBean e non il Dao, ho bisogno di mozzare o deridere il Dao, ma non ho idea di come potrei farlo con Junit.unit-testing un ejb3.0 che ha un altro iniettato di ejb

sto usando Junit4 e EJB3.0

@Stateless 
public class ProcessorBean { 

    @EJB 
    private Dao dao; 

    public void process() { 
     //logic to be tested 
    } 
} 

risposta

3

C'è qualche supporto in OpenEJB si potrebbe trovare utile in combinazione con beffardo.

In alternativa all'API EJBContainer EJB 3.0 Embedded, è possibile semplicemente creare l'app in codice.

import junit.framework.TestCase; 
import org.apache.openejb.jee.EjbJar; 
import org.apache.openejb.jee.StatelessBean; 
import org.apache.openejb.junit.ApplicationComposer; 
import org.apache.openejb.junit.Module; 
import org.junit.Test; 
import org.junit.runner.RunWith; 

import javax.ejb.EJB; 

@RunWith(ApplicationComposer.class) 
public class ProcessorBeanTest extends TestCase { 

    @EJB 
    private ProcessorBean processorBean; 

    @Module 
    public EjbJar beans() { 
     EjbJar ejbJar = new EjbJar(); 
     ejbJar.addEnterpriseBean(new StatelessBean(ProcessorBean.class)); 
     ejbJar.addEnterpriseBean(new StatelessBean(MockDao.class)); 
     return ejbJar; 
    } 

    @Test 
    public void test() throws Exception { 

     // use your processorBean 

    } 
} 

Qui vediamo un banco di prova gestito dal ApplicationComposer. È un semplice wrapper per un runner di test JUnit che cerca i metodi @Module che possono essere utilizzati per definire la tua app.

Questo è in realtà il modo in cui OpenEJB ha eseguito tutti i test interni per anni e qualcosa che abbiamo deciso di aprire nelle ultime versioni (dalla 3.1.3). È oltre potente ed estremamente veloce poiché elimina la scansione del percorso di classe e alcune delle parti più pesanti della distribuzione.

Le dipendenze Maven potrebbero apparire in questo modo:

<dependencies> 
    <dependency> 
     <groupId>org.apache.openejb</groupId> 
     <artifactId>javaee-api</artifactId> 
     <version>6.0-3-SNAPSHOT</version> 
     <scope>provided</scope> 
    </dependency> 
    <dependency> 
     <groupId>junit</groupId> 
     <artifactId>junit</artifactId> 
     <version>4.8.1</version> 
     <scope>test</scope> 
    </dependency> 
    <!-- 
    The <scope>test</scope> guarantees that none of your runtime 
    code is dependent on any OpenEJB classes. 
    --> 
    <dependency> 
     <groupId>org.apache.openejb</groupId> 
     <artifactId>openejb-core</artifactId> 
     <version>4.0.0-beta-1</version> 
     <scope>test</scope> 
    </dependency> 

    </dependencies> 
+0

caratteristica molto interessante. Non sapevo * che * su Open EJB - grazie per aver condiviso! –

+0

@David Blevins In questo caso, MockDao.class è uno sviluppatore implementato falso del DAO giusto? – Bala

+0

@Bala Esattamente. Quindi teoricamente Mockon potrebbe lanciare un'eccezione fingendo un insuccesso di persistenza o qualcosa del genere, o essere cablato per restituire una specifica Entità, ecc. Le classi interne statiche funzionano bene, quindi il Mockon potrebbe essere definito proprio nel caso di test. La maggior parte dei test unitari in OpenEJB tendono ad avere un sacco di fagioli "test" statici di classe interna. I fagioli test (noti anche come fagioli finti), tendono ad essere piccoli ed è bello tenerli insieme. –

1

Se si vuole prendere in giro qualsiasi oggetto o creare la stub, è possibile utilizzare libreria aggiuntiva, ad esempio, Mockito. Ti permette di prendere facilmente in giro qualsiasi classe o anche un'interfaccia.

Letture addizionali:

Problemi correlati