We just gave our "Synaesthesia:
Listening to the Tests" talk at QCon. The exercise helped us to clarify what we want to say about our ideas on Test-Driven Development.
For a more eye-churning version of the image, try Nat's blog.
In our experience, where we find that our tests are awkward to write, it's usually because the design of our target code can be improved. The trick is to let your tests drive your development—that's a hint as to why it's called Test-Driven Development. You can sensitize yourself to find the rough edges in your tests and use them for rapid feedback about what to do with the code. It's rather like Systems Thinking for code: I don't stop at the immediate problem (an ugly test) but look deeper for why I'm in this situation (weakness in the design) and address that†.
As Avi Naparstek once posted to the Test-Driven Development list, the flow for state- and interaction-based testing is different. With state-based testing, where objects are exercised in small clusters, I tend to clean up within the cluster when there's enough code to see what's happening; the design effort happens in bursts. With interaction-based testing, the design is more continuous. The tests are finer grain, so they're more active in shaping the code.
We'll be writing up some test "smells" and what they might mean on this blog.
† With proper Systems Thinking, I should carry on a few more levels and think about how I ended up with a weak design in the first place, but that's for another day.
