In TDD, why OpenEJB and why Arquillian?

Question

I'm a web developer ended up in some Java EE development (Richfaces, Seam 2, EJB 3.1, JPA). To test JPA I use hypersonic and Mockito. But I lack deeper EJB knowledge.

Some may argue that we should use OpenEJB and Arquillian, but for what? When do I need to do container dependent tests? What are the possible test scenarios where I need OpenEJB and Arquillian?

Please enlighten me :)

Subcontraoctave

Answer 1

There are two aspects in this case.

1. Unit tests. These are intended to be very fast (execute the whole test suite in seconds). They test very small chunks of your code - i.e. one method. To achieve this kind of granularity, you need to mock the whole environment using i.e. Mockito. You're not interested in:
   • invoking EntityManager and putting entities into the database,
   • testing transactions,
   • making asynchronous invocations,
   • hitting the JMS Endpoint, etc.

You mock this whole environment and just test each method separately. Unit tests are fine-grained and blazingly fast. It's because you can execute them each time you make some important changes in code. If they were more complex and time-consuming, the developer wouldn't hit the 'test' button so often as he should.

1. Integration tests. These are slower, as you want to test the integration between your modules. You want to test if they 'talk' to each other appropriately, i.e.:
   • are the transactions propagated in the way you expect it,
   • what happens if you invoke your business method with no transaction at all,
   • does the changes sent from your WebServices client, really hits your endpoint method and it adds the data to the database?
   • what if my JMS endpoint throw an ApplicationException - will it properly rollback all the changes?

As you see, integration tests are coarse-grained and as they're executed in the container (or basically: in production-like environment) they're much slower. These tests are normally not executed by the developer after each code change.

Of course, you can run the EJB Container in embedded mode, just as you can execute the JPA in Java SE. The point is that the artificial environment is giving you the basic services, but you'll end with tweaking it and still end with less flexibility than in the real container.

Arquillian gives you the ability to create the production environment on the container of your choice and just execute tests in this environment (using the datasources, JMS destinations, and a whole lot of other configurations you expect to see in production environment.)

Hope it helps.

Pinchhit

Thank you, perfect answer. The JMS part is especially interesting in my case. – Subcontraoctave

Glad I could be of any help :-) – Pinchhit

Good write-up. I am curious on what "The point is that the artificial environment is giving you the basic services, but you'll end with tweaking it and still end with less flexibility than in the real container" is intended to mean. The idea behind the EJBContainer API is that you are using the real EJB container. There shouldn't be any difference in compliance or behavior. – Timberlake

@DavidBlevins Thanks for pointing this out. Yes, you're right - the services are the same. I was referring more to the instrumentation-like services like controlling your EJB's pool or settings specific to the concrete Application Server which will be set in the production environment. I guess I just didn't put it in words correctly. As a side note, I think it's better to put the configuration of the container loosely coupled from the test code. It makes the code clearer and more concise (in my opinion of course). – Pinchhit

@PedroKowalski Yep. With the old InitialContext approach you could use a jndi.properties file. After the spec closed it occurred to me we forgot to add something similar for the EJBContainer API, say an embeddable.properties file or something similar. Of course for OpenEJB specifically you can use plain system properties or an openejb.xml file. – Timberlake

Answer 2

I attended Devoxx this year and got a chance to answer the JBOSS dudes this question. Some of the test scenarios (the stuff i managed to scribble down):

• Configuration of the container
• Container integration
• Transaction boundaries
• Entity callback methods
• Integration tests
• Selenium recordings

Subcontraoctave