Community
Participate
Working Groups
Pain point EJB developers have no easy way to test their EJB artifacts. They need to install an EJB-enabled appication server that typically consumes significant resources on their developer's machines. JUnit tests have to be written manually from scratch. Solution EJB developers would appreciate tools that enables them to easily test developed EJB artifacts. Such tools could be: * a framework for generating JUnit test stubs out from EJB beans. * a lightweight EJB container that runs locally and enables developers to test their EJB beans without a need of full-blown Java EE application server. * an integration between the JUnit generation framework and the lightweight EJB container where the tests would be executed.
I have just found OpenEJB - an Apache project that provides a lightweight EJB 3.0 container. Project site: http://openejb.apache.org There is also an Eclipse plug-in provided: http://openejb.apache.org/openejb-eclipse-plugin.html
I have just posted a blog about installing OpenEJB server adapter in Eclipse: http://dev.eclipse.org/blogs/raev/2008/08/01/lightweight-ejb-container-in-eclipse/ We may start thinking about embedding OpenEJB in the J2EE Preview runtime.
There are from my point of view several ways to test EJBs. In-container. The ejb is running in an ejb container. All injections are valid. The test is run in the same container in the form of another ejb. Out-side the container. The ejb is running in an ejb container. Test is run outside the container. Probably in a separate virtual machine. The test is getting a reference to the ejb and is remotely executing some tests for the ejb. This JUnit test might be written -in a form of a servlet that is injecting the ejb. The servlet is running on the server side. -in a form of a client project that is looking up for the ejb using the InitialContext and is executing tests for the ejb. Again client projects are executed on server side. -in a form of standalone junit test that is running on the client side. Connecting with the server, looking up a reference to the bean, calling methods of the bean. Since looking up a bean from the server with the InitialContext is server depended, what WTP, and server adapters could provider is a way to generate this lookup. Mocking is also a good technique for testing ejbs. No need to have the container. The basic principle for writing good tests is "to test only your code". This mean the code of the ejb. One should not need to test the container, so she should not need to run ejb in a container. I think it is best to unit test the ejb as a simple java class outside of the container using simple JUnit tests. With simple design decisions the ejb can be easily mocked. For example: injection. As the ejb spec states one can inject a bean using -field @ELB private LocalInterface bean; -method @EJB public void setBean(LocalInterface bean). Using the first approach the bean can not be mocked. But with the second approach injection can be very easily mocked. No need from a container. I thing that embedding a lightweight EJB container is not a bad idea, but testing ejbs is not enough for taking such a decision.
I have opened bug 265952 for embedding OpenEJB in the J2EE Preview adapter.
