Mocks Aren't Stubs by Martin Fowler, is a very comprehensive look at two pairs of issues in testing: state-based verification vs behavior verification, and classical TDD vs Mockist TDD.

In light of the recent conversations about the adoption of developer testing on the junit list and Artima, this Turing Award lecture by Robert Floyd seems particularly appropriate. There's a particularly good quote where he is discussing a quote from Thomas Kuhn in "The Structure of Scientific Revolutions."

"Again from Kuhn:

"The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work."

In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development. "

In early August J.B. Rainsberger gave a webinar on TDD for J2EE:

Test-Driven Development is often introduced through simple examples, but many developers would rather dive into the deep end. This free webinar is for those people. J. B. Rainsberger, author of "JUnit Recipes," will show you architecture and design strategies to make it easier to "test-drive" J2EE components. You'll learn how to build a J2EE application while following the cardinal rule of Test-Driven Development: Never write a line of production code unless somewhere, a test has failed.

The recorded webinar is up on the Agitar website linked from this page. Registration is required but if you'd rather not register try out bugmenot.com.

It is critical to remember that Dos Equis Driven Design (XXD) is not about the beer. (I'm not saying there was no beer involved, but that isn't the point...)

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.

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."

If you ever feel yourself drawn toward writing a static method, obey Kevin's Maxim: "in an object-oriented language the simplest thing that could possibly work is an object."

Keith Ray says utility functions are a code smell and I wholeheartedly agree.

BTW I often use the Adapter Pattern to wrap a class that seems to need utils until eventually the Adapter grows into a whole new class of its own. I have done this to add utility functions for parsing and xpath querying to org.w3c.Document for example.

What’s that? It’s code that you’re so proud of that you want to take it home and hang it on the refrigerator, right alongside of your children’s drawings.

...one major advantage of TDD is the ability to answer the question "how will I know I am done?". We can aswer that question because we have a test that will fail if we are not done and pass if we are.