Модульное тестирование EJB 3.1 - PullRequest
7 голосов
/ 14 октября 2011

Я занимаюсь небольшим исследованием модульного тестирования EJB 3.1.В конце моя цель - создать простое в использовании решение для модульного тестирования EJB 3.1.

  1. Я не очень разбираюсь в больших реализациях EJB и, следовательно, хотел бы сначала получить несколько опытных рук (Вы) просто объединить свои идеи о том, что сложно в модульном тестировании EJB.
  2. После первоначального исследования, которое я уже провел, я могу понять преимущества использования фреймворков для модульного тестирования, а не использования встроенных контейнеров.Несмотря на то, что оба хороши, фреймворк стоит немного выше, когда дело доходит до модульного тестирования.Встраиваемые контейнеры, конечно, очень хороши и имеют свои преимущества, но это может быть другая фаза модульного тестирования.Я все еще считаю, что должны быть некоторые недостатки, по крайней мере, в некоторых сценариях использования таких платформ, которые можно улучшить.

Я надеюсь, что смогу сделать полное решение для модульного тестирования EJB, которым я могу поделиться в этомФорум закончен.

Спасибо за вашу поддержку.

Ответы [ 3 ]

14 голосов
/ 16 октября 2011

Я бы посоветовал вам не попадать в общую ловушку, которую я вижу, которая заключается в том, что вам нужно выбирать между насмешкой и использованием встроенного контейнера EJB.

Вы можете использовать оба, вы должны использовать оба, и там, где вам трудно использовать оба, вы должны требовать лучшей поддержки и большего количества функций из вашего контейнера EJB.

Конечно, вы найдете людей в OpenEJB действительно благосклонными и более чем счастливыми, добавив функции, позволяющие получить лучшее из обоих миров. Почти все действительно хорошие функции были созданы на основе запросов пользователей, пытающихся сделать что-то очень специфическое и испытывающих трудности.

Стандартный API EJBContainer

package org.superbiz.stateless.basic;

import junit.framework.TestCase;

import javax.ejb.embeddable.EJBContainer;

public class CalculatorTest extends TestCase {

    private CalculatorBean calculator;

    /**
     * Bootstrap the Embedded EJB Container
     *
     * @throws Exception
     */
    protected void setUp() throws Exception {

        EJBContainer ejbContainer = EJBContainer.createEJBContainer();

        Object object = ejbContainer.getContext().lookup("java:global/simple-stateless/CalculatorBean");

        assertTrue(object instanceof CalculatorBean);

        calculator = (CalculatorBean) object;
    }

Полный источник здесь

Это сканирует путь к классу и загружает все бины.

Без сканирования, более легкий подход к издевательствам

Немного другой подход, когда вы определяете все в коде. Очевидно, что mocking проще, так как вы можете предоставить имитационные реализации bean-компонентов там, где это необходимо.

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

    @EJB
    private Movies movies;

    @Resource
    private UserTransaction userTransaction;

    @PersistenceContext
    private EntityManager entityManager;

    @Module
    public PersistenceUnit persistence() {
        PersistenceUnit unit = new PersistenceUnit("movie-unit");
        unit.setJtaDataSource("movieDatabase");
        unit.setNonJtaDataSource("movieDatabaseUnmanaged");
        unit.getClazz().add(Movie.class.getName());
        unit.setProperty("openjpa.jdbc.SynchronizeMappings", "buildSchema(ForeignKeys=true)");
        return unit;
    }

    @Module
    public EjbJar beans() {
        EjbJar ejbJar = new EjbJar("movie-beans");
        ejbJar.addEnterpriseBean(new StatefulBean(MoviesImpl.class));
        return ejbJar;
    }

    @Configuration
    public Properties config() throws Exception {
        Properties p = new Properties();
        p.put("movieDatabase", "new://Resource?type=DataSource");
        p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
        p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
        return p;
    }

    @Test
    public void test() throws Exception {

        userTransaction.begin();

        try {
            entityManager.persist(new Movie("Quentin Tarantino", "Reservoir Dogs", 1992));
            entityManager.persist(new Movie("Joel Coen", "Fargo", 1996));
            entityManager.persist(new Movie("Joel Coen", "The Big Lebowski", 1998));

            List<Movie> list = movies.getMovies();
            assertEquals("List.size()", 3, list.size());

            for (Movie movie : list) {
                movies.deleteMovie(movie);
            }

            assertEquals("Movies.getMovies()", 0, movies.getMovies().size());

        } finally {
            userTransaction.commit();
        }
    }
}

Полный источник здесь

Конечный результат

Соблазнительно сосредоточиться на различиях между различными типами тестирования и т. Д., Но, безусловно, есть что сказать о прагматичной середине. Лично я не вижу ничего плохого в том, что я могу как можно более свободно смешивать стили «единица» и «интеграция».

Конечно, это замечательная цель. Мы приветствуем идеи и пожелания, чтобы приблизить нас.

5 голосов
/ 18 октября 2011

На самом деле вы можете рассмотреть два различных типа тестирования (не исключая):

  • Модульное тестирование : в конце дня ваши EJB-компоненты являются POJO, и поэтому вы можете использовать предпочитаемую платформу для модульного тестирования (например, JUnit), а также фальшивую среду, такую ​​как Mockito или EasyMock.
  • Интеграционное тестирование : здесь вы хотите протестировать EJB-компоненты, как если бы они находились в контейнере (а не в изоляции), и поэтому вы должны каким-то образом эмулировать этот контейнер. Вы по-прежнему можете использовать свою среду модульного тестирования для кодирования своих тестов (например, JUnit), но теперь вы тестируете, как эти EJB-модули ведут себя в контейнере и взаимодействуют с другими соавторами (например, другими EJB-компонентами), которые они могут иметь. Для этого я бы рекомендовал Arquillian
3 голосов
/ 29 октября 2012

Вы можете использовать Needle для модульных тестов компонентов Java EE.

Needle - это облегченная среда для тестирования компонентов Java EE вне контейнера в изоляции.Это сокращает код настройки теста путем анализа зависимостей и автоматического внедрения фиктивных объектов.

http://needle.spree.de

...