модульное тестирование ejb3.0, в который внедрен другой ejb

Как выполнить модульное тестирование ProcessorBean? Поскольку я не хочу тестировать только ProcessorBean, а не Dao, мне нужно заглушить или смоделировать Dao, но я понятия не имею, как я могу сделать это с помощью Junit.

Я использую Junit4 и Ejb3.0.

@Stateless
public class ProcessorBean {

    @EJB
    private Dao dao;

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

unit-testing dependency-injection junit4 jakarta-ee
person Sven    schedule 03.01.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

В OpenEJB есть некоторая поддержка, которая может оказаться полезной в сочетании с насмешками.

В качестве альтернативы EJB 3.0 Embedded EJBContainer API вы можете просто создать свое приложение в коде.

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

    }
}

Здесь мы видим тестовый пример, запущенный ApplicationComposer. Это простая оболочка для запуска тестов JUnit, которая ищет @Module методов, которые можно использовать для определения вашего приложения.

На самом деле именно так OpenEJB проводил все свое внутреннее тестирование в течение многих лет, и мы решили открыть его в нескольких последних выпусках (начиная с версии 3.1.3). Это сверхмощный и чрезвычайно быстрый, поскольку он исключает сканирование пути к классам и некоторые из тяжелых частей развертывания.

Зависимости maven могут выглядеть так:

  <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>
person David Blevins    schedule 03.01.2012
comment
Очень интересная функция. Не знал этого об Open EJB - спасибо, что поделились! - person Piotr Nowicki; 04.01.2012
comment
@David Blevins В этом случае MockDao.class - это разработчик, реализовавший подделку DAO, верно? - person Bala; 11.01.2012
comment
@ Бала Точно. Таким образом, теоретически MockDao может генерировать исключение, имитирующее сбой сохранения или что-то в этом роде, или быть запрограммированным для возврата определенной сущности и т. д. Классы Static Inner работают нормально, поэтому MockDao можно определить прямо в тестовом примере. Большинство модульных тестов в OpenEJB, как правило, имеют набор статических тестовых компонентов внутреннего класса. Тестовые бобы (также известные как фиктивные бобы), как правило, маленькие, и их приятно держать вместе. - person David Blevins; 11.01.2012

arrow_upward
1
arrow_downward

Если вы хотите смоделировать какой-либо объект или создать его заглушку, вы можете использовать дополнительную библиотеку, например. Мокито. Это позволяет вам очень легко имитировать любой класс или даже интерфейс.

Дополнительное чтение:

person Piotr Nowicki    schedule 03.01.2012