I’ve battled the EJB beast and come back scarred and wounded. I’ve tried many approaches and found none to satisfying.

First, there was hope with MockEJB, I got it working for some simple cases, but I got bogged down with more complicated test setups and dealing with intercepting EntityBean test methods.

Next came the idea of just using EasyMock. That worked well for testing the service layer that depends on some stateless session bean facades. You can mock the session beans pretty effectively by adding a simple setter and injecting the mock. Unfortunately the stateless session beans had lots of JNDI calls within methods to get entity beans. Without wholesale refactoring it just wasn’t going to work.

Then, touched on JB Rainsberger’s idea of pulling out as much logic as possible out of the session beans and just delegating to that class for everything. Unfortunately the session beans already need some refactoring because they’re too big. They implement a Transaction Script style. They make a JNDI call to get a home interface to an entity bean. Then they invoke a method or two on the entity bean. They catch exceptions, rollback transactions, and throw a new wrapped exception. There’s not a lot of real logic anyway except maybe for a bit of exception handling. I can look up the enitity bean home interface and pass it off to the pure POJO class, but I’m still stuck with try catch block. It just isn’t very satifying.

There were a few other attempts, that came to nothing as well.

Large legacy EJBs suck for testing.

I actually see people putting the cart before the horse. They want to go out and buy a registry. I’ve actually talked to a really large company. “We just bought a registry, we spent a lot of money.” I said, “Great how many services are you gonna put in that registry?” “Well we have three or four. And my point with those folks is, “You could keep up with that in an email or a wiki page. Why do you need a registry for three or four services.”

A lot of vendors will talk about governance. You have to have governance, if you don’t have governance you can’t build out an SOA. My point is if you don’t have services you can’t build out an SOA. Let alone governance to actually maintain, monitor, and manage the five services that you actually have.

— Bret Sutter

I actually chuckled out loud on my way home.

I once thought Javadoc was a great tool. I added an ant target for every project I built. Now it’s just clutter. I saw another example of the pain point of Javadoc again recently on an internal project that isn’t designed to ever be used as an API:

/*
* Returns Publisher when passed Id
*/
public Publisher getPublisherById(String id)

/*
* Returns Publisher when passed Id
*/
public Publisher getInstitutionById(String id)

Just drives me crazy the comments fall out of sync with the code as soon as someone performs a cut and paste. And the darn things can double the number of lines in a class, especially when you have a lot of short methods. (And you should have a lot of short methods.) Uggh.

I had a lingering issue resolving connection to an outside VPN and getting into a CVS repository for weeks. I’ve been on and off trying to get it resolved between typical management tasks. Today I mentioned it as an impediment in Scrum where I’ve volunteered to do some coding. By 1:30 in the afternoon the problem had been solved. Sign of a Scrum Master on the ball.

Testing legacy code is tough. It was never designed for tests. The app uses EJBs including old fashioned entity beans. After spending some time trying to get a few tests written against a stateless session bean using MockEJB, I hit upon a new idea. Maybe I want to test at the Business Delegate layer and just mock the calls to the stateless session bean.

With a little dash of EasyMock and a bonus setter method to inject the stateless session bean I now can start opening up a seam for future tests. I’d still like to test the EJB layers, but now I have a seam in the application to work from. (Kudos to Michael Feathers for naming the technique)