How To Unit-Test EJB 3 ...in 0.8 Seconds [source code included]

EJB 3 are just annotated classes - so it is straight forward to unit-test them. However, you will have to "emulate" the Dependency Injection and boot the EntityManager by yourself. It will cost you few additional lines of code. EJB 3.1 will solve the problem entirely - with an embeddable container.  Meanwhile you can use openEJB for boot the entire container within Unit-Test:


public class HelloBeanTest {
    private Hello hello;

    @Before
    public void bootContainer() throws Exception{
        Properties props = new Properties();
        props.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");
        Context context = new InitialContext(props);
        hello = (Hello) context.lookup("HelloBeanLocal");

    }

openEJB provide an own JNDI-SPI implementation, and plugs so naturally as JNDI-provider. Only one line (the bold one) makes your dependent on openEJB. You could even factor out the settings into jndi.properties. You will get from the lookup a fully-featured EJB 3 with injected dependencies and persistence (additional, but still lean, configuration is required here)


    @Test
    public void hello(){
        assertNotNull(hello);
        String message = "hugo";
        String echo = hello.hello(message);
        assertNotNull(echo);
        assertEquals(message,echo);
    }

The EJB is just an usual one:


public interface Hello {
    public String hello(String message);
}

@Stateless
@Local(Hello.class)
public class HelloBean implements Hello{

    public String hello(String message){
        return message;
    }
}

The whole source, project and needed libraries are pushed into: http://kenai.com/projects/javaee-patterns/. openEJB is lean - the only problem is the amount of libraries needed to run the test. I would prefer a single JAR. Maven, however, solves the problem for you in general.

Btw. I would really like to test Glassfish v3 Embeddable Container - should be available soon...

[This sample is not in my book :-)] 

Comments:

Am I missing something here? I thought one of the main benefits of DI was making it easier to test without the container - just create an instance and set the dependencies you need in the test class. Instead, you're using openEJB to do the injection; assuming the class actually has some dependencies, unlike HelloBean, you're going to have to configure openEJB with the appropriate mocks & dummies ahead of looking up the bean being tested. Granted openEJB may well be more lightweight than Websphere or whatever you're eventually using for the app, but you're just swapping one container for another and introducing another set of configuration when you could just inject things yourself...

Posted by Frank Baum on June 25, 2009 at 05:02 PM CEST #

@Frank,

you are right, I'm using hand-made injection with e.g. mockito in the majority of my projects as well. openEJB is, however, an interesting alternative. You could use openEJB for integration tests and tests of interceptors etc.

Wait for the next post :-)

regards,

adam

Posted by Adam Bien on June 25, 2009 at 07:03 PM CEST #

Hello Adam,
funny, I was playing with OpenEJB myself the last few days.

I am amazed how good the project is documented and how easy the examples are.

Up to now everything just worked: Interceptors, Timers, Message Driven Beans ...

However I came across one little issue: If you have several tests, each instantiating a container, then the container instance seems to be shared between the tests.
Basically I dont like this (shared state accross tests)...
I found a "undocumented", that destroys the container, wehn closing the context.

In my tests I am now destroying the container after each test. What do you think about this? Do you think this is overkill?

I blogged about this here:

http://blog.jonasbandi.net/2009/06/restarting-embedded-openejb-container.html

Posted by Jonas Bandi on June 26, 2009 at 02:13 AM CEST #

We've used a spring-based setup for testing successfully in the past - with a few lines of configuration it successfully wired our EJBs for test purposes (and it was running live without the spring framework even getting deployed).

What's missing from this example for me is injecting the EJBs into the test class itself, this manual lookup looks sooo 90's ;)

Posted by Kristof on June 26, 2009 at 10:31 AM CEST #

I purchased your book. I am having a very difficult time accessing the site for your source code: http://kenai.com/projects/javaee-patterns/. The site is terribly slow.

Is there any way to get the source files as a single downloadable zip file?

Thanks.

Posted by Daniel Miklancic on April 28, 2010 at 04:01 PM CEST #

Hi Dude, is there any way we can include unit tests in build process for EJB3 as well ?

Thanks
Javin

Posted by Javin Paul on February 15, 2011 at 06:07 PM CET #

Very nice info , also in process of reading your book on EE patterns.

Posted by pranav on August 14, 2011 at 09:08 AM CEST #

Hi guys! Had anyone of you have an issue of making OpenEJB be used as a client container? That is not an embeddable one but rather making run an application on the side of the server in an alloted container.
Something on it was said in

http://tomee-openejb.979440.n4.nabble.com/How-to-use-annotation-in-client-application-td980967.html#a980968

But I was unclear with that information.

Posted by Pavel P. on August 30, 2015 at 12:16 PM CEST #

Hi,

What I don't really understand with this kind of solution, is what you get when you are dependent on different appserver resources.

For e.g.: What do you get if the EJB is dependent on an EntityManager?
Or if it is dependent on the JMS Connection factory?

Thanks

Posted by Csaba on November 03, 2015 at 11:39 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License