How To Unit-Test EJB 3 ...in 0.8 Seconds [source code included] : Adam Bien's Weblog

How To Unit-Test EJB 3 ...in 0.8 Seconds [source code included] : Adam Bien's Weblog Adam Bien's Weblog « Generic CRUD Service... | Main | Unit Testing EJB 3.1... » 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 :-)]  Posted at 11:00AM Jun 25, 2009 by Adam Bien , Comments[9]  | Views/Hits: 906 NEW workshop: HTML 5 and JavaScript Essentials , Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming. Newsletter: airhacks.news A book about rethinking Java EE Patterns 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/