Testing an EJB 3.1 device

Question

I am doing a little research on Unit Testing EJB 3.1. In the end, my goal is to create an easy-to-use unit testing solution for EJB 3.1.

• I don’t have much knowledge with large EJB implementations, and therefore I would like to get some experienced hands (You) first, just to combine your ideas about what is difficult in EJB unit testing.
• With the initial research that I have already done, I can understand the benefits of using fake frameworks for Unit Testing, rather than using built-in containers. Although both are good, mocking frameworks are a little taller when it comes to Unit Testing. Embedded containers are very good and have their advantages, but can be different stages of unit testing. I still think that in some scenarios there are some drawbacks to using such frameworks that can be improved.

I hope I can make a complete solution for Unit Eing, which I can share on this forum after completion.

Thanks for your support.

Answer 1

My advice to you would be to not fall into the common trap that I see, which is to think that you need to choose between mocking and using the built-in EJB container.

You can use both options, you must use both options, and where it is difficult for you to use both, you should demand improved support and additional features from your EJB container.

Of course, you will find people in OpenEJB truly supportive and more than happy to add features to support the best of both worlds. Almost all really good features were created around user requests that try to do very specific things and find it hard.

Standard EJBContainer API

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

Full source here

This scans the classpath and loads all the beans.

No scan, simpler calculation approach

A slightly different approach in which you define everything in code. Obviously, taunting is easier, as you can provide mock beans implementations where necessary.

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

Full source here

Final result

It is tempting to focus on the differences between different types of testing, etc., but of course there is something that can be said about the pragmatic middle. I personally do not see anything wrong with the ability to mix the styles of "unity" and "integration" as badly as possible.

Of course, this is a wonderful goal. Ideas and feature requests to get closer to us are very welcome.

Answer 2

There are two different types of testing that you can consider (not exclusive):

• Device testing . Your EJBs are POJOs at the end of the day, and so you can use your preferred unit testing module (like JUnit), as well as a mocking structure like Mockito or EasyMock.
• Integration testing : here you want to test EJBs as if they were in a container (not isolated), and therefore you have to somehow emulate this container. You can still use your unit testing infrastructure to code your tests (e.g. JUnit), but now you are testing how these EJBs behave in the container and interact with other employees (e.g. other EJBs) that they may have. For this, I would recommend Arquillian

Answer 3

You can use the needle to unit test Java EE components.

A needle is a lightweight structure for testing Java EE components outside a container in isolation. It reduces test setup code by analyzing dependencies and automatically injecting mock objects.

http://needle.spree.de