I wonder where Frank learned his test-first? I suspect that he hasn't ever sat down and paired for a significant time with a master of the art. It is a skill and can't be picked up just from reading about it and having a bit of a go. Also, test-first is only a transitional practice to test-driven, which is where the big wins come from.
In any case, I find Frank's appeal to the theory of flow to explain why he doesn't enjoy test-first programming rather bizarre. He quotes Csikszentmihalyi on some of the characteristics of flow:
And suggests that they are in conflict somehow with the practice of test-first. I find the exact opposite, and I'm not alone in that. I'm going to talk more about TDD than merely test-first, because I don't practice the one without the other any more.
- 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 find that test-driven development is the way that I turn programming into an activity with the right amount of challenge. I'm just not smart enough to program any other way. I did somehow manage to get paid to program in the days before I adopted TDD, but I no longer understand how that can possibly have happened. YMMV.
In writing a TDD test I am explicitly setting an clear an unabiguous goal for the next few minutes programming.
The red bar -> green bar -> refactor cycle provides very clear-cut and very immediate feedback on my programming activity.
And, as Frank rightly points out, test-first works best on a very small scale. In fact, TDD encourages you to program in very small steps (and, perhaps counterintuitively, the smaller the steps the faster you make progress). So I find that writing the tests first encourages me to center on the present.
Fascinating that two people can have such utterly opposed experience with the same technique.
3 comments:
It is a skill and can't be picked up just from reading about it and having a bit of a go.
I'm assuming that when you say, "a bit of a go" you mean superficial dabbling. If not then I'm screwed because I don't have access to any masters of the art. I only have books and blogs to turn to.
From whom did you learn your TDD skills?
Hi Bong,
You probably aren't completely screwed, but your certainly will be severly restricted in how far you can develop your TDD skills.
I learned a lot of what we would now call TDD from a chap called Rob Whittick who, long before he or I had learned about Extreme Programming demanded that all programmers working for him spent a large proportion of their time writing tests. He carried an automated testing framework around in his head, which he reproduced in each new job--originally it had been in Pascal, but by the time I knew him it had got to C++. He demanded automated test cases for every item of functionality, and demanded that they all pass before a check-in. This was all-but TDD, except that we were allowed to retro-fit tests to code after it was written (but before it was checked in).
Since XP arrived on the scene, I have learned from and along with the fellow XP practicioners that I've worked with--sometimes in an employment setting, and sometimes not.
And I have leared from blogs and books, but not nearly so much as setting down at a computer with a pair and writing some (preferably paid-for, production) code test-first, and test-driven.
Where are you located? It may not be so hard to get to meet a master of the art as you think. You could even try doing some remote pairing, in this age of widespread broadband. I'm not sure I'd count as a "master", but depending on time-zones I'd be happy to try doing some remote pairing with you myself.
Keith,
That's a very generous offer you make. I'm in Lansing, Michigan (GMT -5). I know of a group who are test infected. While they're only an hour's drive away they're so busy with their own day jobs to do much mentoring or remote pairing. They will happily do some coaching for a fee, though. I'm not holding my breath. It's hard enough convincing management that a small pilot project to familiarize ourselves with new and unknown technology makes more sense than using the same on a critical and high-profile project.
I wonder who Rob Whittick learned from? I'm sure that the notion of TDD has independently occurred to several programmers. Much of what was previously folklore has been refined and somewhat codified as more and more people use the technique. I find it funny in a haha-seriously way that there's even two camps forming around mocking versus state assertions. I'm just glad that I at least have a fighting chance. Perhaps someday I will get a chance to pair up with someone who has not only used TDD but has actually thought deeply about it.
Thanks!
Post a Comment