Testy jednostkowe EJB 3.1

Przeprowadzam małe badania na temat testów jednostkowych EJB 3.1. Na koniec moim celem jest stworzenie łatwego w użyciu rozwiązania do testowania jednostkowego EJB 3.1.

  1. nie mam zbyt dużej wiedzy na temat implementacji Big EJB i dlatego chciałbym najpierw zdobyć kilka doświadczonych rąk (ty), aby po prostu połączyć swoje pomysły na to, co jest trudne w testowaniu jednostkowym EJB.
  2. dzięki wstępnym badaniom, które już wykonałem, mogę zrozumieć zalety używania szyderczych RAM do testowania jednostkowego zamiast używać osadzonych kontenerów. Choć oba są dobre, szydercze ramy stoją nieco wyżej, jeśli chodzi o testy jednostkowe. Osadzone kontenery są oczywiście bardzo dobre i mają swoje zalety, ale mogą być inną fazą testów jednostkowych. Nadal uważam, że przynajmniej w niektórych scenariuszach powinny istnieć pewne braki w stosowaniu takich frameworków, które można poprawić.

Mam nadzieję, że uda mi się stworzyć kompletne rozwiązanie do testów jednostkowych EJB, którymi mogę się podzielić na tym forum raz zrobione.

Dzięki za wsparcie.

Author: Bala, 2011-10-14

3 answers

Radzę ci, abyś nie wpadł w wspólną pułapkę, którą widzę, czyli pomyśleć, że musisz wybrać między wyśmiewaniem a używaniem wbudowanego kontenera EJB.

Możesz używać obu, powinieneś używać obu, a tam, gdzie jest ci trudno używać obu, powinieneś wymagać lepszego wsparcia i więcej funkcji z kontenera EJB.

Z pewnością znajdziesz ludzi w OpenEJB naprawdę wspierających i bardziej niż szczęśliwi, aby dodać funkcje wspierające uzyskiwanie najlepszych z obu światów. Prawie wszystkie naprawdę dobre funkcje zostały stworzone wokół próśb użytkowników, którzy próbują robić bardzo konkretne rzeczy i trudno im to znaleźć.

Standardowy interfejs 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;
    }

Pełne źródło tutaj

To skanuje classpath i ładuje wszystkie fasolki.

Bez skanowania, łatwiejsze podejście do szyderstwa

Nieco inne podejście, gdzie definiujesz wszystko w kodzie. Oczywiście szydzenie jest łatwiejsze, ponieważ w razie potrzeby można dostarczyć makiety fasoli w will.

@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();
        }
    }
}

Pełne źródło tutaj

Wynik końcowy

Kuszące jest skupienie się na różnicach między różnymi rodzajami testów itp. ale na pewno jest coś do powiedzenia dla pragmatycznego środka. Osobiście nie widzę nic złego w możliwości płynnego mieszania stylów" unit "i" integration". Oczywiście, to godny podziwu cel. Pomysły i prośby o funkcje, aby nas zbliżyć, są bardzo mile widziane.
 14
Author: David Blevins,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-16 03:43:56

Istnieją właściwie dwa różne rodzaje testów, które warto rozważyć (Nie wyłączne):

  • testowanie jednostkowe : twoje EJB są Pojo na koniec dnia i dlatego możesz użyć preferowanego frameworka do testowania jednostkowego (np. JUnit), a także frameworka do szydzenia, takiego jak Mockito lub EasyMock.
  • Integration testing : tutaj chcesz przetestować EJB tak, jakby były w kontenerze (nie w izolacji) i dlatego musisz jakoś to emulować Pojemnik. JUnit), ale teraz testujesz, jak te EJB zachowują się w kontenerze i wchodzą w interakcje z innymi współpracownikami (np. innymi EJB), które mogą mieć. Do tego polecam Arquillian
 5
Author: Gonzalo Garcia Lasurtegui,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-18 12:46:55

Możesz użyć igły do testów jednostkowych komponentów Java EE.

Needle jest lekkim frameworkiem do testowania komponentów Java EE poza kontenerem w izolacji. Redukuje kod konfiguracji testowej poprzez analizę zależności i automatyczne wtryskiwanie obiektów wzorcowych.

Http://needle.spree.de

 3
Author: Heinz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-28 20:27:40