If you write a test and it passes, the question is if the previous step was too big.
The DRY principle doesn’t talk about code, but knowledge.
Clever is never something to be proud of in your code.
A couple of days after attending the code retreat facilitated by him, I was fortunate to attend Corey Haines’s “Improving Your TDD” workshop at the Agile Practitioners 2012 conference. These are some of my notes from the day.
The workshop was intended at coders familiar with TDD and not introductory. I was very interested to see how in-depth TDD training looks, and also meet other coders from Israel that have been doing TDD for a few years. It was quite awesome to sit in a room where everyone felt comfortable with TDD and it wasn’t this new and hard thing. When the group shares this “advanced” technique, discussion can suddenly level up and we could all dive in to the nitty gritty stuff.
During the day, Corey walked us through pretty much taking TDD apart and putting it back together. We started from the history of TDD and its predecessors (manual verification, test after, test first, etc.).
The exercises throughout the day (that I especially enjoyed since I was pairing with @theyonibomber, my original pair as we were learning TDD together back in 2006) had this beautiful flow of making you smack right into a problem in the way most people do TDD.
We discussed having the tests drive an implementation that we knew we did not want (like sorting easily become bubble sort) and how the (relatively new) Transformation Priority Premise by Uncle Bob can help solve this.
We then took another introspective look at our TDD process (aided by an exercise once more) that made us face the problem of “flailing” and “sitting in red” – basically the problem of trying to take a step too big in the next test and so falling off the good fast rhythm of “time to green”.
We had a long discussion about these problems and how they are directly connected to the way we pick the next test. We all know that the next test should be the “simplest thing”, but how exactly do we define simple?
I love having these discussions that jolt me and make me rethinks stuff I’ve long ago stopped paying attention to. Developer introspection is a thing of beauty and much power (Kent Beck tells that he wrote his incredible Smalltalk Best Practice Patterns and Implementation Patterns books by simply stopping whenever he was about to type some code and have an explanation as to why he picked to do it that way).
and 
books by simply stopping whenever he was about to type some code and have an explanation as to why he picked to do it that way).Corey even did a live demo of his TDD style and programming by wishful thinking. It was very interesting, but as all live demos go he had some trouble along the way. Workshop aside, it is not trivial for someone giving a training to admit a mistake done, and Corey gracefully handled the situation.
All in all, the day was a very productive one and it still has me chewing on some of the lessons we learned. It’s fun realizing again that there’s no limit to how much one can sharpen a specific skill. Hat off to Corey and the conference organizers for making this happen!