A Deceptively Simple Idea

Test-Driven Development (TDD) is a deceptively simple idea: write the tests for your code before writing the code itself. We say “deceptively simple” because this reversal fundamentally changes the role that testing plays in the development process and challenges the industry's assumptions about what testing is for. Testing is no longer just about keeping defects from the users, instead it's about helping the team to understand the features that the users need and to deliver those features reliably and predictably. When followed to its conclusions, TDD radically changes the way we develop software and, in our experience, dramatically improves the quality of the systems we build, in particular their reliability and their flexibility in response to new requirements.

Miško Hevery has written a great summary of some basic coding rules for testability in his post Writing Testable Code.

I love this quote because every time I introduce unit testing to someone who has an existing code base you can see this in their eyes:

"I understand how to write tests for your code, but my code is different"

He goes on to list the rules most often broken by developers that make unit testing hard in his top ten list:

Hank Wallace turned me on to a post by Allison Shapira where she summarizes a key point from Rob Walker's writeup of the Blue Man Group - the "Why To" manual.

This "Actors' Journal" is not so much a how-to manual as a why-to manual; it's not about stage directions, but rather tells the story of the show step by step, from the point of view of the Blue Men. As a decoding and deconstruction of Blue Man's at-times baffling, even mystical behavior, it's a fascinating document, thick with references to everything from Being There to George Bernard Shaw to Robert Motherwell to the caves of Lascaux. Some explanations are straightforward — "The Blue Men are not aliens" — and others are more subtle, as when the trio's harmonic "three as one" relationship is described in terms of "blesh," a mix of blend and mesh borrowed from Theodore Sturgeon's science fiction novel More Than Human.

What would a "Why To" manual look like for a development team?