Chapter 3

Ruby Eye for the Java Guy

Rails For Java Developers

One of those silent chuckle to yourself moments.

Apparently JB’s entry on Wikipedia is up for deletion. He comments on the whole process of the debate around his deletion as:

The whole experience makes me feel like I’m in a room with people talking about me while not acknowledging my presence and not seeming to care what I think about that.

I can’t even believe there’s a debate around it. JB has obviously contributed much to unit testing, TDD, XP, and Agile in general. His book, JUnit Recipes, I still use as a reference when I run into a nasty testing problem. I re-read sections on testing EJBs just a few days ago and it was better than anything you can find by just googling around. He’s hosted workshops at XP conferences, run XP days, written a popular JUnit tutorial. I still love his post on BDD:

What is Behavior-Driven Development (BDD)?

It is Test-Driven Development (TDD) practiced correctly; nothing more.

For all that work he really doesn’t deserve this sort of treatment.

In number the great bulk of projects I see are small maintenance or minor enhancement projects. They’re done in a day or a week or two by a single developer. Adding anyone or even the overhead of something like Scrum is counter-productive.

My assumption has been you hand off the assignment and let the individual self-organize with say a business analyst, QA person, and maybe a PM. I wonder if they’re aren’t some emerging ideas on how to handle this from the Agile community. I know some people organize a maintenance list and just pull things off a prioritized backlog when they have downtime.

The best way to tell if your one developer project is Agile. The developer and business analyst meet the documentation requirement by emailing back and forth a one page or less document and the PM runs it around for signatures a bit before or sometimes a little after the code has been pushed out to production. The only thing we typically miss is some way to do an inspect and adapt cycle.

Developers have no love of estimates. They’ve been pinned in a corner by an estimate and beaten to a pulp. “But you said it would be done by Friday!”

I don’t have any problem with a developer being reluctant to give an estimate. I do have a problem with developers refusing to give estimates unless they have everything nailed down in a nice spec document and they’ve completed their design.

You can’t know everything when you give an estimate, hence the term. You base your estimate on breaking down the work you think will need to be done into small enough tasks and then build from there. You take into account risks and any historical information you have. Then you give an estimate.

The business has a right to expect this. In no way does this mean the estimate will play out exactly. If it does, likely it was an overestimate and the developer simply backed into it. Estimates will get adjusted by reality. As you get more information you can update estimates and give better future estimates. Scrum builds this into the process as you change your estimates every day. The important point is how many hours you have left on a task or whether you finished it, not whether the actual time you spent on a task lined up with your original estimate.

Rant done.

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.