MockEJB framework

MockEJB News

MockEJB Article on BEA dev2dev

MockEJB 0.6-beta2 released
Changes: Security support, improved BMP.

MockEJB 0.6-beta1 released
Changes: Entity bean support, new AOP framework.

What is MockEJB?

MockEJB is a lightweight framework for running EJBs. MockEJB implements javax.ejb APIs and creates Home and EJBObject implementation classes for your EJBs. Internally, MockEJB relies on dynamic proxies and interceptors. MockEJB has two primary usages:

It allows for running EJBs outside of the container for unit testing.You can run EJBs directly from your favorite IDE with the minimal setup effort.
It allows for deploying mock EJBs (i.e., mock EJB implementation classes) into the container. Mock EJBs provide very effective way of isolating EJBs under test from the rest of the application. Mock EJBs return predefined test data and can override the actual "non-mock" deployed EJBs. Once again, the purpose of MockEJB is twofold and it works inside and outside of the container. So you can benefit from it even if you continue running all your test classes inside the container using Cactus.

Additionally, MockEJB comes with the "mock" implementation of non-EJB APIs. Currently it provides in-memory JNDI and JMS implementations which can be used independently from MockEJB's EJB support.

MockEJB is not a full-blown EJB container. It does not fully implement J2EE/EJB specs, however it supports all vital APIs.

What are the advantages of running EJBs outside of the container?

Deploying EJBs into a container oftentimes becomes a complex operation requiring to run custom scripts and proprietary deployment tools. On the other hand, EJBs are the key components of J2EE applications and usually expose important application APIs/interfaces that must be properly tested.

So it is desirable to be able to edit/compile/run EJBs directly from IDE and avoid costly redeployments into the container. This is especially true if you follow test-driven development practice in which case quick edit/compile/run cycle is a must.

Therefore, the main advantage of testing outside of the container is the improved developers productivity and the quality of the tests.

How MockEJB is better than instantiating and invoking a bean (Impl) class directly?

MockEJB allows you to test EJBs that:

Rely on JNDI.
Call other EJBs.
Have logic in ejbCreate/ejbRemove methods.
Use EJBMetaData, SessionContext and other javax.ejb APIs.
Need container-managed transaction support.
Rely on container's CMP services.

What are the advantages of using mock EJBs?

J2EE applications usually are pretty complex, they consist of multiple layers and modules. This means that any given EJB may depend on a number of other EJBs. So, to be able to test an EJB efficiently, one needs a strategy of isolating the EJB under test from the rest of the application by minimizing its dependencies on other parts of the application that are not in scope of the test.

MockEJB framework gives you the ability to replace these out of scope EJBs with the classes returning data suitable for your test. Therefore, the changes in the other parts of the application won't affect the functionality of your test.

MockEJB framework creates mock EJBs in such a way that they only exist for the duration of the test. In other words, mock EJBs don't affect the actual "non-mock" EJBs already deployed in the container.

Mock EJBs also allow you to write tests for non-EJB classes that have dependencies on EJBs (e.g., Struts action classes). You can run these tests with or without the container.

Isn't EJB technology complex? How can it be implemented by a lightweight framework?

EJBs are simple if you just want to run them for the purpose of testing your business logic. In this case, the support for numerous features defined by EJB spec is not really needed. You probably don't care too much about instance pooling, proper EJB lifecycle and clustering support when you just want to run your test and see if it passed.

This is the key design principle of MockEJB. It only focuses on what's relevant for unit testing and it leaves true enterprise-strength EJB support to the J2EE application server vendors.

What EJB capabilities are currently supported?

Stateless and stateful session beans.
Local and remote interfaces.
Message-driven beans with the ability to deploy to mock JMS destinations.
EJBMetaData.
EJBContext.
Container-managed transactions.
Exception handling.
CMP and BMP entity beans (with some limitations).
Security (with limitations).

What EJB capabilities are not currently supported ?

Some methods on EJBObject/EJBLocalObject.
SessionSynchronization interface.
Handles.

While only a subset of EJB spec is supported, you can always extend MockEJB using interceptors.

MockEJB License

MockEJB is available under Apache License 2.0.

Stay tuned and please sign up for our mailing list.