2012-01-03 10 views
5

¿Cómo puedo probar la unidad ProcessorBean? Como solo quiero probar el ProcessorBean y no el Dao, necesito tropezarme o burlarme del Dao, pero no tengo idea de cómo podría hacerlo con Junit.pruebas unitarias ejb3.0 que tiene inyectado otro ejb

estoy usando Junit4 y EJB3.0

@Stateless 
public class ProcessorBean { 

    @EJB 
    private Dao dao; 

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

Respuesta

3

Hay algún apoyo en OpenEJB le puede resultar útil en combinación con burla.

Como alternativa a EJB 3.0 Embedded EJBContainer API, simplemente puede compilar su aplicación en el código.

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 

    } 
} 

Aquí vemos un caso de prueba ejecutado por el ApplicationComposer. Es un contenedor simple para un corredor de prueba JUnit que busca los métodos @Module que se pueden usar para definir su aplicación.

Así es como OpenEJB ha hecho todas sus pruebas internas durante años y algo que decidimos abrir en las últimas versiones (desde 3.1.3). Es más que poderoso y extremadamente rápido, ya que elimina el escaneo classpath y algunas de las partes más pesadas de la implementación.

Las dependencias de Maven puede tener un aspecto así:

<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

característica muy interesante. No sabía * que * sobre Open EJB - ¡gracias por compartir! –

+0

@David Blevins En este caso, MockDao.class es un desarrollador implementado falso de DAO ¿verdad? – Bala

+0

@Bala Exactamente. Entonces, teóricamente, MockDao podría lanzar una excepción falsificando una falla de persistencia o algo así, o estar cableado para devolver una Entidad específica, etc. Las clases internas estáticas funcionan bien, por lo que el MockDao podría definirse directamente en el caso de prueba. La mayoría de las pruebas unitarias en OpenEJB tienden a tener un montón de granos de "prueba" de clase interna estática. Los granos de prueba (también llamados frijoles simulados) tienden a ser pequeños y es bueno mantenerlos juntos. –