[Previous entry: "Test-Driven J2EE: an update"] [Next entry: "Ah, learning tests!"]
03/10/2005: "TDD evangelist? Moi?!"
"October" says, about JUnit Recipes...
This is a book that should be on the bookshelf of any Java developer. I just finished implementing a continuous integration system here on my team, and I leave this one out on the corner of my desk. It disappears usually once a day, as the team starts to get up to speed on automated unit tests. I highly recommend it. My only quible with it is a general quibble I have with many things I read written by TDD evangelists: it assumes that the reason organizations don't refactor to support easier testing is laziness, inertia, fear, etc. How about because the system works as is, and trying to sell refactoring of a working system to project stakeholders is a tough sell? How about timelines are tight enough to just to hit the critical must have features that customers are demanding? Yes, I know testing is important. Believe me. However the system has a lot of EJBs that need to be run in container. I've mocked out where I can, where it makes sense, but applying things like Inversion of Control is going to have to be done over time.
I don't remember being a TDD evangelist when writing JUnit Recipes. I tried rather hard not to be, simply saying, "Here's what I'd do if I had my choice. If you can't do that, do this instead." This explains why there are so many recipes for dealing with legacy code that one can't change to bring under test. (For more on this topic, thou shalt read Working Effectively with Legacy Code.) Evidently, here is one case where I failed at my objective.
I don't have the energy to go back and re-read the book, because it's quite big and I have Too Much to Do as it is. When I do, I'll likely be embarrassed by the strength and naivete of some of my opinions about the importance of testability. I likely did a little soapbox speaking, and I apologize for that. My only defence is this: it had to be done.
Today, I counsel people to examine the tradeoffs between refactoring to support testing and testing legacy code as is. In examining the tradeoffs, I try to point out to people a few things:
- The gain (in reduced costs) from refactoring is usually much more than people think.
- The cost of refactoring is usually less than people think, if they have the right guidance.
- The extra earned value from getting software tested sooner is more than most people realize.
