During my days as a developer I have never become as hooked to something as when the TDD way of working found me. During development of a spring framework "managed" application it was evolved to an addiction. Coming back to JEE again 2 years ago got me really annoyed and the result is the following tooling.

I have now developed TDD with EJB3 (so has my team of developers) for 6months or so and perhaps even you can!?

The tooling is in Release Candidate condition, most APIs' are working as intended, but I do not support everything needed. Basically @EJB works and any service can be injected, also the @PostConstruct performs as intended.

The key values for this tooling are these

- Speed, the "boot" time of the Container should be close to zero. (aim was < 100ms)
- Automated "lifecyclehandling" of Container and DB-tx (clean up after tests)
- Minimal config for JEE server "services" (like JTA, DataSources)
- Very easy replace single EJB services during test execution (useful for mocking)

See the follow blogpost on the subject: http://alexandersson-robert.blogspot.com/2011/05/tdd-framework-for-ejb3.html

The jar can be found here http://code.google.com/p/injection-extensions/downloads/list

Maven dependency are synced to maven central and can be found in blogpost.

It's obviously up to you -- but I would consider joining something like JBoss Arquillian, Apache CODI Testing or CDISource Testing instead of spawning yet another Java EE 5/6 testing framework (on the flip side, of course more choices for developers is better).

Before Arquillian came along, I used OpenEJB with Spring/JUnit for testing my Java EE 5 projects.

It's obviously up to you -- but I would consider joining something like JBoss Arquillian, Apache CODI Testing or CDISource Testing instead of spawning yet another Java EE 5/6 testing framework (on the flip side, of course more choices for developers is better).

Before Arquillian came along, I used OpenEJB with Spring/JUnit for testing my Java EE 5 projects.

Hi.

I actually started with OpenEJB and creating a wrapper for JUnit for it. But it was very unstable and slow, our project had boot times of 6-7seconds. In the end we dropped it as it stopped working on different developers workstations for so many reasons I could not even count them.  And it started working again for similar odd reasons.

An interresting project to join forces with would be Arquillian. 

For info, the underlying Container is also custom and created by me (an JSR-330 container with "ejb support"). It is via this container I can do the "speed booting of container", "rebooting of the container" and "single service replacement". If a tool like arquillian would support this container and somehow support the three features mentioned above "rebooting" feature I would love to join. But we do have a pretty large difference in approach, Arquillian want service config for each test class. I do it with the running config class, this means you can reuse it as many times as you want between test classes. Also I support scanning services in addition for programmatic single service mapping.

Hmm - I hope David (Blevins) sees your stability concerns and follows up personally (maybe this was before OpenEJB 3.0 was releases?). Like I said though - the more options the better.

Good luck with Arquillian integration - we are actually doing it ourselves with the Resin embeddded container. Aslak is a good guy and is also from Scandinavia :-).

It might not be OpenEJB's problem. Our software was created for the J2EE Container Oracle OC4J and has more that a few issues with the XML for the old EJB2.1's. It works for OC4J but will not deploy on any other servers.

Well anyhow thanks for the feedback :) and I will most likely continue to develop this and try to get in touch with Arquillian as this is the only project so far I have found that has the same approach as mine.

regards Robert

I have been using Cactus for quite a while now and have not had any complaints. How different is this?

Awesome -- another Cactus user! I used Cactus quite a bit back in the day for EJB 2 testing while everyone else was whining about how untestable EJBs were :-).

All kidding aside, Cactus is a lot harder to use than solutions like this as well as Arquillian, CODI Testing, OpenEJB, etc. Unlike Cactus, with these solutions containers are embeddded, which means you don't need an external app server up-and-running that you need test components deployed to. Everything can run simply inside the IDE's JVM via JUnit.

This project sounds to me like an OpenEJB (embedded container) with JUnit integration (like Cactus). I think it's best these guys and OpenEJB join forces :-). OpenEJB is a very cool embedded container for testing - it could use better JUnit integration.

Yes, the big difference from Cactus like testing is that its "in container" just as Reza explains it.

It's also integrated with JUnit lifecycle handling to help the developer with common issues. This is what atleast I think makes it different from most other TDD utilites out there. Have not tried or used them all though and do not think what I have done is the "solution" to it all, I am just doing this to hopefully help some other developers out there who need to test thier EJB's.

This is the JUnit integrations that are supported (via the utility and the underlying container)

Pre test features (before @Before, but after @BeforeClass)
- Container Creation (mapping the EJB's and Resources needed) 
- DB script execution, for creating schemas needed (if lacking jpa auto-create) or if you simple need some small amounts of data in the DB before tests start to execute 

Test features (during @Test)
- Single service replacements (good for partial mocking of EJB services)
- JPA flush/clear, good if you need the test to force the insert/update/delete before next step is executed.
- DBUtil, if you need to change the base data for the DB for this single test (is "undone" by the automated rollback of DB-tc on post test). This is still not working and will be part of RC3.

Post test features (after @After but before @AfterClass)
- The container restarts between tests (any single service replacements during test is reset)
- All opened DB-tx's is rolled back between tests (any insert/update/deletes executed in the test)