Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Wed, 10 Mar 2004

Where's the creativity in test-driven design?

Michael Hamman has a couple of posts on creativity. In the first, he defines creativity as, in part, the desire to create a problem. In the second, he speaks of generating creativity by inventing friction.

Michael made me think of creativity and test-driven design. Consider my story of a refactoring episode. In it, I claim that the end result was surprising. And it certainly felt like something like creativity was going on. But where did the creativity lie? After all, what I was doing seems to be fairly straightforward rule-following: I saw two if statements that test the same thing, so I removed the duplication by creating subclasses. Then I made some code more intention-revealing. I iterated until there were no more "impulsive" rules telling me of code to clean up.

Is the creativity somewhere else in the TDD micro-iteration? Is it in the tests? Maybe, but not enormously. The tests are mostly responses to outside impulses (at the highest level, from customer desires). And the coding doesn't seem hugely creative, either, since it's mainly a matter of getting the next test to pass in a straightforward way.

I'm not even quite sure how to pose the issue, but it goes something like this: the end result appears to be the product of a creative process. However, the process, when examined, doesn't seem creative. It seems fairly mechanical, fairly rote rule-following. However, it doesn't feel mechanical from the inside: coding the dullest code test-first is nothing like the experience of sweeping the floor, though to the outsider they might not look intrinsically different.

Part of what's going on, I think, is that the creativity is distributed. It's more a matter of a series of small aha moments than fewer big AHA! moments.

But a bigger part, perhaps, is that the creativity lies more in retrospective discovery than invention. I said something like the following to myself: "Oh, you know that thing I created to get rid of duplication back then? Now I see that changing its name turns it into a potentially sensible - even suggestive - object in the domain model." Discovery. Or consider Ward Cunningham's story of Advancers.

An Advancer is a MethodObject. I first created an Advancer to hold all of the temps used in the otherwise unrefactorable advance method in WyCash.[...]

We came to think of computations in terms of the Advancers we would need. [...] The mere existence of Advancers shaped the way we thought. We got more done. We did it faster. We wrote less code. We had fewer bugs. [...]

We enjoyed the benefits of Advancers for many months before we discovered their real calling. We had been having persistent problems with a few tax reports. [...] Finally, out of frustration, we began to look around for other objects that might help, and there was Advancer.[...]

I don't know if Ward's talking about the same sort of thing I am. I shall have to ask him. In any case, understanding a bit more where my feeling of creativity comes from might help me get it more often - or more justifiably.

## Posted at 21:26 in category /agile [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo