I’m working on a Java EE 6 application. When I started out, I was writing tests for my EJB classes by manually instantiating the EJB, then manually adding the members that normally get provided by dependency injection. As the application gets more complicated, I find that this approach just doesn’t cut it. So I’d like to be able to start my own EJB container in the test framework, so it can manage my beans. What’s the best way to approach this? I’ve heard of javax.ejb.embeddable.EJBContainer, are there other options?
(I’m using Glassfish 3, and building with Maven, if that makes any difference.)
What exactly are you testing? Logic? Configuration? Do you NEED to test the EJB classes directly? Would it suffice for your tests to behave as an EJB client against a running container? (Remember there’s no rule that says automated unit tests can’t require a running system-under-test.)
If it’s business logic you need to test, move that code into POJOs and test normally; you wouldn’t need to then test the POJOs running in a container, as the container shouldn’t affect the business logic.
In a related situation, I have never directly JUnit-tested a servlet class or a Struts controller class. I definitely test the POJOs those depend on, and I test the end application (running in a servlet container, tested with HtmlUnit), assuming that if the end app works, then the plumbing works too.