I had to review a proposal for reworking one of our major applications today. The application has a lot of inherent issues, but one of the interesting things was the solution involved a bunch of Stateless Session Bean Facades. Would have been a reasonable solution except they were describing an application that was to be completely contained in a single J2EE container. The system connects to a legacy mainframe application and a relational database. It of course doesn’t do distributed transactions. So I’ve got no idea why EJBs were proposed.

I’m guessing the Session Facade was proposed by default because a lot of consultants in the Java world are still selling EJB as the way to go. I half expect to get the ‘Enterprise’ development argument when I get together for feedback. The argument goes something like, well you wouldn’t want to build an application without EJBs, how will it scale. Core J2EE Patterns has been updated with a ServiceFacade pattern which allows for a POJOFacade Implementation. Maybe this is why I prefer the mentoring consultant model where the consultant’s major goal is to get a team up to speed.

I’ve been running through an on site use case class as we start to formally role out our Agile (Scrum based) methodology. The formalness of the rollout I find a bit over done, but buy-in is important. And generally management finds if easier to buy in if a consultant presents these ideas. Anyway despite having done a lot of use cases for requirements gathering in the past six years or so there’s always new techniques or tips to pick up. Some I got from the class today were:

• Use Simple Use Case Templates – I learned this the hard way after putting together elaborate Word templates in the past complete with nicely formatted tables and nested numbered lists. After many hours in Word cleaning up formatting I finally stopped using tables and simplified my numbering system as much as possible.
• Combining Alternative Paths and Error Paths – Apparently the instructor and I had learned the same lesson that it is really hard sometimes to define whether something is an Error Path versus just an alternative Path. Since the point is just to describe all the paths who cares if it’s an error path or an alternative path, just make everything an alternative path.
• Big Sketch Pads versus Projectors – My past experience has been using a projector with the use cases and going through each step with everyone in the room looking on. The instructor mentioned that she preferred to use a lot of sketchpads so more people could interact. She felt you got more of a visual sense of accomplishment and more of the important thoughts and details could be captured because everything doesn’t have to be funneled through the person at the one keyboard. I’ll have to try this out the next time I get a chance to do some use cases.

I’d never been really excited about setting up TestSuite classes like the classic AllTests in JUnit, but today I ran across an alternative. From a podcast at SwampCast, Jim Moore talks about a best practice being avoiding writing TestSuites.

Obviously they’re a bit of a pain and can be problematic to maintain, but often you need to break up at least the easy to run tests from the ones that are dependent on an actual database connection or a web GUI being up and running in a container. So you end up with something like GuiTestSuite that you only run with Cruisecontrol. Moore’s suggestion is to try to never write TestSuites. Simply use introspection in the various IDEs or in ant’s

task with the

tag. In order to avoid running dependent tests put them in another package like:

So if you have say some functional tests that run against say the actual web interface like JWebUnit you only run them if you include this package.

I do a lot more dishes these days. Turns out popping on a podcast on say Ruby means a lot more dirty dishes get done. Never would have guessed podcasts would spruce up household chores.

Last week I filled out a purchase order for Clover after some evaluation of various unit testing code coverage tools. I went with Clover because $1500 for the server edition isn’t really that significant a cost even if the experiment doesn’t work out. So starting next week we’ll be running code coverage reports with our ongoing projects. I expect the feedback loop to be pretty helpful. I’ll be really happy at first if we can get 50% coverage at first on average.