Thoughts from a Thirsty Bear

Following a fairly public spat and veiled threats over trademarks by Oracle, the Hudson CI server has been renamed to Jenkins . OK, technically Jenkins is a branch of the Hudson code, so it's more like Hudkins or Jenson . Oracle (sorry, " the Java community ") will continue to develop the Hudson trunk, however the branch appears to have the blessing of the core Hudson Jenkins development team and the community (the vote to fork appears to have been virtually unanimous ). If it looks like a duck & quacks like a duck....then the parent might just start resembling a dodo . I'd like to wish the Jenkins team good luck. I've used Hudson to great effect many times, and look forward to the future improvements with the new project butler.

I'll be attending the Lean Software & Systems Conference in Long Beach, California 3-6 May. I'm not in the States very often any more, so make the most of it. Come over and introduce yourself!

Something is happening in the Test First world. There appears to be growing use of " Behavioural Driven Design " (BDD). That is, the test names in test classes are becoming sentences describing what the class should do, eg testFailsForDuplicateCustomers() . In my opinion this trend is damaging the effectiveness of Test First Design in the field. Don't get me wrong - I think the fundamental idea behind BDD is sound. But I am finding that this kind of naming approach for unit tests is seriously detracting from the "code is the documentation" ideal. If you have a class with method " X ", you should expect a test method " testX " that defines the method's contract. If the method's contract is more complex, you might expect to see a set of methods like " testX_NullInput " etc. This approach documents the class pretty damned well in my experience. Now image the same class being tested by something like " testFailsIfC