EJB testing strategies?

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.

I've heard of javax.ejb.embeddable.EJBContainer, are there other options?

The EJBContainer API is an option. The other one would be to use Arquillian (and SchrinkWrap).

Some more links:

• Real Java EE Testing with Arquillian and ShrinkWrap (slides + audio)
• Test drive with Arquillian and CDI (Part 2)
• Arquillian in Action; New Features Coming Soon

I'm not entirely sure if that helps your case, but have a look at Smokestack. I personally don't work in the EE space (outside of the Servlet spec) but I did see a presentation on this at one point and looks like it can do what you need.

Now there's Arquillian, developers should not need to fiddle around with embedded Java EE containers anymore.