Mocking a singleton is relatively easy.

To begin with, singleton's are all alone in the world; don't be afraid to point this out. Also, most singletons are created, get this, not even in a factory, but merely in a factory method. Finally there is the point that they are little more than dressed-up globals, and IME experience cause more heartache than they're worth. You can point to the many nasty screeds about singletons there are out on the net. All in all, mocking it shouldn't be too hard. A word: if your singleton has unusually large body parts, stoop to insulting that. Sometimes, to be kind, you have to be cruel.

CruiseControl 2.5 has just been released and it has two huge bug fixes:

• Updated Xerces and Xalan jars to fix memory leak (CC-426)
• ProjectWrapper: Fix problem where forcing a build while build is running will effectively kill the worker thread leading to all projects queued but not building (CC-431). Patch by John Lewis.

Along with those bug fixes there are a few new plugins:

• ClearCaseBaselinePublisher: New publisher for use with ClearCase UCM (CC-414). Submitted by Kevin Lee.
• LDAPMapper: Email mapper that uses an LDAP lookup to determine user email addresses (CC-413). Submitted by Esa Laine.
• Maven2SnapshotDependency: New sourcecontrol (CC-438). Contributed by Dan Rollo with fixes by Jerome Lacoste.

So what are you waiting for? Go get it...

Next week Agitar is hosting Ted Husted of the Struts development team (and iBATIS and MyFaces and Jakarta-Commons) in a webinar on What to Do if Your Code Has Few, If Any Tests?. I'm curious to hear what Ted has to say but his talk illustrates the kind of trade-off that exist as our company grows. One the one hand we can having interesting speakers and topics like this, but on the otherhand we're now scheduling the webinars for a global audience, so the scheduled times (7 am and 5 pm PDT) probably work better in just about every other timezone than this one. (</whine>)

Brian Marick says that tests are not specifications but I believe there is a more fundamental distinction.

In math geek terms, specifications are universally quantified statements, ones of the form "for all inputs such that <something> is true of them, <something else> is true of the output." Tests are constant statements, ones with no variables. They look like this: "given input 5, the output is 87."

The main focus is fixtures but it also has some helpers for creating continuous integration scripts. This was all designed around subversion post-commit hooks and there is even a handler for you to run a SimpleXMLRPCServer.

It doesn't matter if you call it Refrigerator Code or Girl Code or Beautiful Code or simply Clean Code, the meme is out there that is isn't enough to say the code works and then leave it at that. Even if you find yourself unmoved by Kathy's aesthetic arguments you should weigh Uncle Bob's assertion that "keeping your code clean is not just cost effective; it’s a matter of professional survival."