This post originated from an RSS feed registered with Ruby Buzz
by Eric Hodel.
Original Post: TDD and Creative Flow
Feed Title: Segment7
Feed URL: http://blog.segment7.net/articles.rss
Feed Description: Posts about and around Ruby, MetaRuby, ruby2c, ZenTest and work at The Robot Co-op.
A couple weeks ago I came across a discussion of whether test-first development was an impediment to creative flow based on an entry by Frank Sommers.
When I first started testing I found testing was an impediment to my flow. I didn’t know how to write my programs to be easily testable. My methods were too big, too coupled or just plain wrong.
What I did start to see was immediate feedback on whether I was going in the right or wrong direction. If I wrote a test and was quickly able to make it pass I knew I was doing something right. If I wrote a test and couldn’t see a good way of making it pass quickly I knew I was doing something wrong. Getting lost or bogged down quickly destroys flow, so an early-warning system was a big benefit.
When I started down the wrong path I knew before I was in too deep and could rip the code and the test out and either try again or work on some other aspect of the system and let the problem percolate in my brain.
The activity must present just the right amount of challenge: If the activity is too hard, we become frustrated; if too easy, boredom ensues.
There must be clear and unambiguous goals in mind.
There needs to be clear-cut and immediate feedback about the activity’s success.
Finally, our focus during the activity must center on the present – the activity itself.
I eventually came around to having TDD fulfill these requirements much better than the way I was writing code before.
TDD keeps me in the right challenge range. When things become too easy I need to refactor to get rid of the boredom. When things become too hard I’m doing something wrong.
The one I didn’t expect was what the clear and unambiguous goal is. It happens to be getting the next test to pass or fail as appropriate. When they don’t you know you’re doing something wrong.
The clear-cut and immediate feedback is even more immediate with testing. You nearly instantly know if you’re doing the right thing. Did the test fail? Is making the test pass easy? Is writing the next test easy?
Finally, I found myself spending more time writing code and less time chasing down bugs again and again. By testing I reduced distractions and kept developing code at the center of my activity. I no longer have to run through my code sprinkling puts or inspecting in the debugger only to do it over again on the next bug. My tests tell me what’s wrong long before I get to that stage.
Previous Topic
