Lasse is writing a Manning book on practical TDD and acceptance testing for java developers.

I’m so excited I purchased the early access addition, signed up for the author forums, and started skimming the PDF of the first four chapters tonight. This is exactly the text my team and so many other java development teams have needed. Up until now I had a big todo on my Someday/Maybe list entitled:

• Write a developer notebook style on unit testing java web apps (especially TDD with JSF)

Now I’ll actually see the concept in print.

Other Texts

As an early adopter it’s fairly easy to get caught up in TDD and forget how painful it can be to implement or understand for developers in the early majority. In the past I’ve looked at several texts to help transition my team:

Test Driven Development – Beck is great getting across the concept, but when you have to move past implementing a Money class and deal with things like Struts, JSF, or iBATIS and Hibernate the gulf can be hard to cross.

Pragmatic Unit Testing – A good overview text including the idea of fakes and mocking. Jumping to effectively testing a J2EE app is still a wide ravine.

JUnit in Action – Again another good introduction, but some of the solutions to deal with J2EE troubles is to utilize Cactus to do in-container testing. Your testing times really start stacking up.

JUnit Cookbook – A great sample of recipes that finally addresses some of the nastier cases like how you test JSP output. After looking all the ways to deal with testing JSPs I just felt dirty. And because it’s from 2004 it largely ignored the difficult to test world of JSF.

Agile Software Development, Principles, Patterns, and Practices – I love some of the TDD examples in here and the bowling game is a now a classic. Still the gap exists in how to apply this in J2EE land.

Acceptance Testing

Lasse is tackling unit testing the J2EE stack along with acceptance TDD. Introducing Fitnesse has been a big focus for the last year and we’re starting to really utilize it on projects. Still it suffers some in the documentation area and even the one book out focuses on FIT and ignores many of the gotchas that come up on Fitnesse.

While I think TDD has started to move closer to the mainstream, acceptance testing is still fairly leading edge from what I can see. I think quite a few java developers have heard of FIT or Fitnesse, but very few have even tried it out.

Conclusions

This just really bandages up a nasty pain I’ve had for too long around TDD, acceptance testing and J2EE. Two years ago I would have ordered twenty copies, put together some labs, and setup a reading group. It may have cut months of our adoption curb. Since we were more on the leading edge I got to figure out a lot of this as we went along from using the Shale mocking library to driving adoption by making setup easier with ObjectMother patterns.

Just skimming the first four chapters, knowing the quality of Lasse’s postings over the years, and realizing there is still much to learn I expect great things of this book. I’m sure I’ll be ordering a dozen copies come September.

Many thanks to Lasse for spending many future hours hammering out this tome.

About a year ago in a session at SD Forum 2006 Dave Astels related a story on how one manager approached mandating TDD on a team:

• Move the whole team out to a new collocated team room.
• Outfit the team with brand new equipment.
• Brought in Dave to mentor/coach the team on TDD by doing a lot of pairing.
• Mandated that all code was unit tested.
• Mandated user stories and acceptance tests written into Fitnesse.

Impressive story, and probably the sort of boss I’d love to work under. After two years we’ve finally realized much of the goals I set out to accomplish:

All of my developers are writing tests, some TDD and some just in close proximity to writing the code, but average code coverage is 75-80% and defects are down more than 10x from just two years ago.

We’ve put Fitnesse in place and are writing acceptance tests for the first time.

Two of my developers are even pair programming by choice.

It took two years, which feels like a long time to me. Could a shock treatment have worked better? I think given our environment where most of the developers were brand new or relatively new to OO or Java adding in all of the TDD approach would have largely backfired. Maybe we could have done it in a single year, but I’m still really proud of my team.

There’s not much better than knowing that you’ve been able to really grow your team out into a high quality group of software developers conversant in most of the XP practices and constantly willing to learn and improve.

Being right later is a symptom of a nasty disease. You knew the problem was coming, you tried to convince people, possibly even earnestly, but they choose the risky path anyway.

Self reflection reveals:

1. You’re not communicating effectively.
2. You’re not trusted.

Painful, yes, but if all the evidence points one way you have to face it. Many technologists focus on the logic, the details of the arguments, and assume that the overwhelming evidence will win out. Often an emotional appeal will crush an overly rational argument. Since code or mathematics don’t behave this way it can defy comprehension. Heck, many developers ended up coding because it’s such a nice logical world.

The second possibility is that they’re not hearing your arguments because they don’t trust you. That lack of trust can be simple hierarchical status. I’m higher up in the organization therefore anyone lower in the pyramid probably can be safely ignored. It could also be that they’ve tagged you based on some past mistake. Doesn’t matter that you’ve had 10 big successes since then, they’ve mentally checked out of your arguments, because you screwed up on big Project A 5 years ago.

Communication can be worked on and built up. Trust unfortunately tends to be a long term fix. In the mean time you can find yourself wanting to say “I told you so!” constantly, but it’s just counterproductive. If you’ve lost that trust in a corporate setting it’s often just better to be successful elsewhere.

Banks don’t like being dependent on any one particular thing. They like to have a lot of options. Typically, we’ll roll out WebLogic, but we’ll also have JBoss on the side. Who uses Weblogic? IBM Websphere? Anybody use Websphere by choice? No hands at t’all, (Laughter from the audience) I like that one. So for the benefit of the camera half use Websphere and no one uses it by choice.

— John Davies

— Talk on ESBs in the Investment Banks

I sense a wave of disillusionment with IBM Websphere that threatens to end their dominance in commercial application servers. Weblogic has always had a it’s share of detractors and quite a few people get annoyed with the marketing politics of JBoss. Still you can easily find lots of developers who would admit to using either one by choice.

With the application server moving towards more of a commodity item easily dominated by open source competitors like JBoss, Glassfish or even a simple Tomcat server can Websphere sustain charging for enterprise software rates for the Webshpere platform? Not really a sustainable model, though they really make their money in professional services so maybe they’re not that concerned.

And John Davies isn’t some Web 2.0 type. He’s worked for over 20 years in ever so Enterprisey investment banking. He is CTO and co-founder of C24.

Two days at the San Jose Tech Museum hearing about Ruby rejuvenated the old cranium. Just in time since I had spent the previous day doing about 14 hours of troubleshooting on some Enterprise software.

The conference had somewhere above 100 attendees (I didn’t count). It was all in one big hall on the first floor of the Tech. The chairs, well they were bad and know tables to drop a laptop. Still for about $250 for two days I can’t complain too much about the chairs.

The talks ranged from Ruby testing techniques and libraries to IDEs and even into a good bit of depth on VMs and compilers since there were talks on Rubinius and JRuby. At least 10 people in the room had open positions and if you’re a Ruby developer now there’s little chance you can’t find lots of work in Silicon Valley. A decent portion of the audience even had at least one patent.

As a manager dealing day to day with the Java world I felt in over my head as far as Ruby expertise, and it was great. When I go to more general software conferences or Java talks I often get less out of them because I have a lot of experience. Here I was in the bottom third of the class and it was nice. Everything is still shiny and new.

Since there was only one track you didn’t have to do any deciding and walk out of a session feeling like you made a mistake. Another nice part was most of the presenters were very focused and often finished ahead of there hour or so. Instead of sort of filling the time up they generally gave up the floor for lightning talks or answered questions. The self-organization was evident.

Coming down from Sacramento the drive was reasonable, and I just crashed at a $80 hotel room Saturday and headed home Sunday afternoon. Given a really long week at work I didn’t have as much energy as I usually do for socializing, but I did manage to spend some time talking to Cary Campbell of Codecraft. He was trying to get up to speed on Ruby on Rails since he’d spent a lot of time at IBM, 37 years, and the last 15 with embedded systems. He had a great story about setting up a lot of tests based on specs. It sounded like the tests were all written first and then the software was added until all the tests pass. Sort of big test design up front. They were going to use Rails so management could see web reports. Right now if you’re not starting with any legacy web baggage Rails is a great option.