The image above probably needs a bit of explanation. After having a lingering todo I finally made a donation and requested a Green Clean Code band from Uncle Bob Martin. I was at a talk of his at SD West 2005. At that point he pointed out a rubber band he was wearing that he would snap on his wrist every once in a while to remind him to run the tests. It was a mark that he took TDD as part of his professional duties.

The green band you get sits at the top of the image. The yellow band below wasn’t a warning type band. The words on have worn out, but it said ‘Go Kenji!!’. Kenji is the son of a neighborhood friend who was diagnosed about a year and a half ago with Stage IV Neuroblastoma. It was heartbreaking to see him go through chemo radiation and finally a stem cell transplant, but he’s a happy cancer survivor today. Today was a good day to retire the band. Cancer is a nasty disease, but it’s better to move on as soon as you’ve vanquished it.

So next time I run into anyone I’ll be wearing this band as a reminder to always keep my code clean with tests and refactoring, even when that code is hairy or written in some language and frameworks that are inherently hard to test.

Michael Feathers wrote a tough post recently on UI testing tools.

The fact of the matter is that UI based testing should be used for UIs: that’s it. You should not be testing your full application end-to-end through a UI Testing tool. First of all, that sort of testing couples some of the most important tests in your system to one of the most volatile parts of it.

—Michael Feathers

I understand the frustration he speaks from, but I’ve always realized that you don’t really want to completely try to test through the front-end of the application. It can be useful with legacy systems to get a minimal test harness in place. With the right testers I’ve even seen some of the Mercury products used effectively for UI testing, though it probably required a 3-1 ratio of QA to developers and the tests were not customer tests, but written more as a regression suite.

My use of functional testing tools like Selenium has generally been for a spattering of end to end tests and some amount of customer tests. I’ve never really tried to achieve a high level of coverage with these tests. Obviously testing the business logic through something like Fitnesse is more effective or even setting up BDD style tests tend to make better customer tests.

I’ve actually been saddened over the past five years or so to see that tools like Fitnesse haven’t seen more adoption. I think the BDD development has put more of a focus on developing customer style tests, but in general if there are automated end-to-end test suites in place there often overly reliant on something like Selenium.

I came across a note of mine from last year on my baseline expectations for developers:

• All code is checked into source control on an hourly basis or at most daily.
• Every project has an automated build. (Maven, Ant)
• All projects are setup in continuous integration (Hudson)
• All code follows the current Java/Groovy coding standards.
• Unit test coverage of new code must meet a 70% target. TDD is preferred.
• Code reviews or regular pair programming are required.
• Code should meet a standard of low cyclomatic complexity through refactoring and design.
• Some level of functional, integration, and acceptance tests should be performed.
• High value documentation is maintained.

According to a Forester report the multiple IDEs for Java developers is standard practice:

While Eclipse is common, it won’t become the only Java IDE in enterprise IT shops any time soon. Less than one out of five Java developers have a single primary Java IDE and no other.

— Jeffery S. Hammond (Forrester Research)

IDE Usage Trends

As a victim of attempts to standardize on a single IDE, this is a good counter-weight argument. My personal experience is I primarily work on Java code in IntelliJ IDEA, but every once in a while I want to use some specific Eclipse plug-in. More regularly I’ll drop back to TextMate for some Groovy or Ruby work as well.

Despite the efforts of commercial vendors to sell IT management on the concept of higher productivity with their brand of IDE, the idea hasn’t worked. At the end of the day as a developer in any shop I want to know I can pull down a codebase and run an automated build with no IDE at all. I don’t care if the original developer did it in Eclipse or Netbeans. The key to being a successful coding shop is to remember that IDEs are just tools and should never be required to build, test, or deploy an application.

Not too long ago a local recruiter noted at a JUG meeting:

“I don’t care what else you have on your resume, but you have to have Spring and Hibernate. I know it was all EJB and SOA just a few years ago, but now if you don’t have Spring/Hibernate you’re not getting past the HR screen.”

As a development manager and even in my professional services role I tend to screen dozens of resumes. I have noticed the preponderance of Spring/Hibernate taking over the usual emphasis on EJB and Struts on the average mid-level java developer. It’s actually a pleasant change to know that the open source community ended up victorious in the marketing war over the official specifications.

Knowing Spring can mean all sorts of things since it’s a fairly large framework. At a minimum I expect a developer to have an idea of using it for dependency injection, but it’s nice to see some exposure to Spring’s AOP concepts, Spring Security, or even something like Spring Batch. It’s a bounus when they have exposure to something like Grails which has been added to the Spring family and wraps much of the low level Spring items in a nice DSL framework.

With Hibernate most developers have left behind either the old hand rolled JDBC DAO patterns or potentially entity beans. Generally, I expect they can handle any sort of mapping and understand things like named queries, lazy loading, and second level caches that can catch developers new to Hibernate by surprise.

I’ve also noted that jQuery in the last year or so has largely become the winner among Javascript libraries and is typically the most common experience I see on resumes. The days of getting by with largely full page reloads for any new request are gone and the Web 2.0 sites have increased UI expectations even for corporate users.

Looking back a few years it was still the rare corporate shop that cared about frameworks like Spring or Hibernate. The emphasis was on heavyweight solutions like classic EJB or closer to the metal approaches like rolling your own JDBC for every database request. The progress to Spring/Hibernate has been an impressive win for developers wanting something simpler.

I do have a few regrets that JUnit and unit testing are still not a default requirement with most development shops. Almost every java developer has the keyword somewhere on their resume, but I screen enough people to know usually that means they’ve written a handful of unit tests for perhaps one project in their career and really don’t understand the value of it.

I also regret that in Java land there are not a handful of default web frameworks. Instead we have dozens of options. .NET, Python, PHP, and Ruby have been more successful in this arena with a handful of web frameworks to choose from in each camp. Usually if you move to a new job you’re going to have to get up to speed on yet another web framework, because the options are so splintered. Maybe this will consolidate in the next few years. At least with the new languages on the JVM you’re seeing only one or two web frameworks like Groovy with Grails, Scala with Lift, or even JRuby with Rails. The example in Ruby with Rails merging with Merb for 3.0 is something the Java world needs to do more of.

So if you’re a java developer and you haven’t had any real exposure to Spring and Hibernate, I’d advise at least spending some time with some tutorials at home. The economy is bad enough that you never know when you’ll be dropped back onto a fairly hostile job market and you’ll at least need them as baseline skills.