Ship It! A Practical Guide to Successful Software Projects is a really quick read. I’m 100 pages deep now and I’ve got two sides of a 3×5 card filled with new ideas including things like lots of constant buddy/mini code reviews instead of pair programming.

I’m sure I’ll end up experimenting with a bunch of the ideas, and I’m a little surprised at how much I’m enjoying the read. I picked it up thinking it might have some good ideas, but that I probably knew much of the content. I recognize a lot of the ideas, but they’re able to present them in novel ways and cite clever anecdotes that keep my mind really engaged. This is the sort of book that impresses me with the Pragmatic Programmers series.

Of course I did notice one practice they suggest is keeping ‘The List’ of all the project features. The idea is really similar to Scrum’s backlog, but they were inspired by Stephen Covey’s writings on the ‘7 Habits’. Personally I’m more of a ‘Getting Things Done‘ (GTD) fan, and David Allen the unlikely guru suggests that the idea of a daily list really doesn’t work for most people.

I’d have to agree I find I almost always put stuff on a daily list and then fail to get most of it done. All it means is I have to copy it over to the next day and feel guilty about it, not exactly a successful system. With GTD I just stick the item into a context like @Computer and only items that absolutely have to get done on that day get done like ‘Turn in final employee reviews to HR’. I find it to be a much cleaner system. Feels like a more pragmatic approach to me.

Given the amount written about unit testing in general one would think that many organizations had adopted it by now. If XP has done nothing else it had apparently been able to make testing cool with developers. That alone is quite an accomplishment. Some of the signs of its’ widespread popularity include:

• After only a few years there are xUnit frameworks for almost every language from .NET to PHP

• There are many popular open source testing tools beyond xUnit including:

• CruiseControl, AntHill
• HttpUnit, JWebUnit
• Mock testing frameworks EasyMock, JMock
• StrutsTestCase
• Replacements for JUnit like TestNG
• DbUnit

• And many others …

• Support for running JUnit is built into every major Java IDE.
• A whole host of books have been written specifically on unit testing.
• A greater number of books and articles touch on unit testing such as all the XP books.
• Many of the Agile methodologies assume unit testing and automated builds as basic supporting practices. After reviewing a number of resumes, conducting quite a few phone interviews, and a few in person interviews for an opening for a senior J2EE developer I’m starting to seriously reconsider my assumptions. The reality is almost all the resumes I see mention experience with at least JUnit in the list of skills and experience. Then you start asking questions of candidates.

As it turns out over the last 3 months of conducting interviews it’s turned out in every case that the candidates had little real experience writing unit tests. Most of them had apparently used JUnit at least once, but generally didn’t use it on their projects and often the only unit tests they had ever written were written against DAOs which invoked a live database.

Often they’d explain that they used JUnit and unit testing for a project or two, but early on the developers had stopped writing the tests and they were rarely if ever run after being initially written. One explained that they did write a fair amount of unit tests, but they never used JUnit and had instead written their tests into main methods in all their classes that could then be executed individually. In the past three months this is the best I’ve seen as far as good practices go.

I realize that my current experience is a tiny sampling of the IT world out there, but it leads me to believe that a majority of the J2EE development world really hasn’t instituted any significant unit testing practices into their development methodology.

I can see evidence of this even within my own organization. My senior developers run CruiseControl, write a significant number of unit tests, and are constantly researching new testing techniques like Fitnesse or JWebUnit. When I came onboard over a year ago now I was impressed with their level of sophistication in these practices. As things have evolved I’ve of course seen much of the reality.

• We have over 700+ unit tests for our major enterprise application, but it is far to few to truly test the system.
• The majority of the tests are actually functional tests that invoke a lot of database transactions and rules from a commercial rules engine.
• The full test suite runs for over 25 minutes so it’s only run by CruiseControl.
• The majority of the time our build is broken and some unit tests are failing, but fixing current defects from QA almost always outweigh getting the unit tests passing.
• Developers admit that despite believing in unit testing, if they feel any sense of time crunch they opt to stop writing tests first.

So I hope my experience has just been a statistical anomaly, but I fear it’s pretty close to reality. I do know that I personally feel like I’m diving off the deep end into an empty pool if I’m not writing tests. I don’t plan to go back to the days of just hoping everything worked with no tests in place. And I do love green bars and quick feedback. Now I just need to harness some of that passion to bring our development organization along. (And I need to remember not to be so dogmatic, that’s always dangerous)

I just came across the ObjectMother pattern for creating a factory object to provide all sorts of test objects for unit testing. Essentially you create a class or classes with lots of nice static methods that return already setup objects for testing. This is especially helpful on larger projects where you have a lot of code that gets into each

method. I’ll probably try it out on some of my home projects before I try to sell anyone on my team with using it.

Interestingly enough most of the blog entries that come up high when you google for ‘ObjectMother’ are for .NET developer blogs. I don’t know if that says anything about the pattern or not.

It looks like the book, Fit for Developing Software: Framework for Integrated Tests is out. Since we’re just about to embark on a project to make our largest application more testable and especially more testable for QA I hope this book has some good examples. I’ve spent some time with Fitnesse and been able to get a basic understanding at this point, but I feel like I need to see some more real world examples to really get a handle on how you best implement it. Should be interesting to see how our QA department, which is largely used to manual testing, adjusts to it.

I came across a post on a Ruby feature that Todd Huss would like to see in Java:

Native getter/setter support: declaring a list of variables as attr_reader or attr_writer allows getter/setter functionality of a variable without writing/maintaining any redundant getter/setter code, yet if necessary, you can override the default getter/setter behaviour without affecting the API. In Java it drives me crazy that we waste time and clutter our classes unnecessarily with hundreds of lines of getter/setter methods that all do the same thing. Java really needs a construct for default getter/setter behaviour on selected variables that can be overriden when necessary.

I agree that all the clutter and extra lines from getter/setter methods are really annoying within Java code. My preference though is to simply drop the getter/setter methods altogether and make the variable public. Better yet keep it private and don’t expose it to anything, it should be data only the class makes use of to implement behavior.

Allen Holub has an article entitled Why Getters and Setters Are Evil that argues that the getter/setter idiom in java is really not a good idea. If you haven’t read it basically it argues that the getter/setter methods are procedural hangovers that should largely be abandoned.

I remember back when I taught an Intro to Java course or two that there was a wonderful discussion of encapsulation and that one of the examples were the getter/setter methods that encapsulated the private variables. Everytime I covered this topic I felt it was a really weak argument. If you have a private instance variable, but then you just implement default public getter/setter methods, esentially you’re making the variable public again. If that’s the case why not just use the dot syntax and make the instance variable public.

Holub talks about this in his article, but the obvious thing is that the getter/setter paradigm has become standard in Java both by procedural programmers who were used to objects that look like just collections of data and by the default JavaBean implementation. Indeed I occasionally try to leave off getter/setter methods only to find in many frameworks like Struts, Spring, and others that they assume they can use reflection and the get/set methods to implement functionality.

I sat through a session as SD 2005 this year and found Allen’s presentation pretty refreshing since he was taking on established practices in Java. What was amazing was the amount of flak he took for bringing this up from much of the audience.

Anyway I still end up implementing a lot of get/set methods since a lot of frameworks require it, even if it isn’t very object oriented.