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

Thu, 11 Mar 2004

Text files defended

Carlos E. Perez defends loosely-coupled text files against structured data stores.

Very tangentially, I'm reminded of those who claim that the failure of Lisp and Smalltalk was partly due to their being hermetic - taking all data on their own terms, not the world's. They failed to embrace the string and the regular expression.

(Not just to pick on Lisp and Smalltalk, two fine languages: how long did it take for a regex class to make it into Java? And a regex class is one significant affordance notch below regexps built into the language.)

Despite tending to agree with Carlos, I gotta say: it's just so much finer to define functions on the fly in Lisp than in Ruby. For that particular (but important!) purpose, having the parse tree as a first-class data type is just a total win. Within programs, strings are a second-class way to represent code.

## Posted at 20:34 in category /misc [permalink] [top]

Telling the code to tell you something

Two related ideas:

1. Chad Fowler builds on an idea from Dave Thomas to show dynamically-typed code that documents the types it probably wants. Dave's idea was that the first type a method's called with is probably the right type. So, in an aspectish way, you point at the method, tell it to remember how it's called and to complain if later calls are different. Chad's idea is that a method can just as easily record the information in a way that lets you create documentation about the types of method arguments.

   Chad's idea of using the results to inform an IDE is particularly clever.

2. Agitator is a new testing tool that semi-intelligently floods a program with data and records interesting facts about what happens. (Full disclosure: I've received some money from the company that sells it.) Kevin Lawrence tells a story of how the desire to simplify the results Agitator produced for some code resulted in a small class hierarchy replacing much more code smeared all over the place. The end result and the feel of the process is the standard test-driven refactoring story, but the "impulsive force" was interestingly different.

   (See also a different story, from Jeffrey Fredrick. To me, it's a story about how Agitator's large number of examples hinted that there's a bug somewhere and that maybe an assertion right over there would be a good way to trap it.)

The common thread is quickly instrumenting your program, running a lot of ready-to-hand examples through it, getting some output that's not too noisy, and deriving value from that. Not a new idea: how long have profilers been around? But now that "listening to what the code is trying to tell us" is marginally more respectable (I blithely assert), we should expand the range of conversation. It shouldn't be only about the code's static nature, but also about its dynamic nature. And perceiving the dynamic nature should be as simple, as semi-automatic, even as rawly perceptual as, say, noticing duplication between two if statements.

## Posted at 20:30 in category /ideas [permalink] [top]

Engineering as iteration

Good engineering is not a matter of creativity or centering or grounding or inspiration or lateral thinking, as useful as those might be, but of decoding the clever, even witty, messages the solution space carves on the corpses of the ideas in which you believed with all your heart, and then building the road to the next message.

-- Fred Hapgood (via Bret)

## Posted at 14:39 in category /misc [permalink] [top]

The phrase 'exploratory testing'

I don't like the word "test" in "unit test" or "customer test". It leads to endless repetition of sentences like "But don't forget that unit tests aren't really about testing, they're about design." The listener is perfectly justified in asking, "Then why not pick a name that doesn't mislead?" To which, the only real answer is historical accident.

I haven't been enormously comfortable with my use of the phrase "exploratory testing" either. Exploratory testing has historically been a fast and flexible and creative way of finding bugs that matter. My goal for it (in Agile projects) is different. It's to expand the range of possible future stories from which the business expert will choose. Some of those stories might be bug fixes like "make it such that the operating system doesn't crash when you lay a manual on the keyboard and the keys repeat more than about 100 times"¹. But I'm much more interested in stories that are feature requests, ones that suggest adding positive business value rather than removing negative business value.

For a time, I was calling that "exploratory learning" to emphasize that it will use some of the techniques of exploratory testing while still being a different sort of thing. But the name didn't catch on, so I reverted to "exploratory testing." But I'm still unhappy about it.

In the Agile Testing mailing list, Randy MacDonald wrote:

Don't build a system where exploratory testing is possible. Do build a system where exploratory design is possible. In fact, build the system via exploratory design.

I'm thinking that "exploratory design", perhaps with another adjective tacked on front, is more what I'm looking for. So, if I start using that, this will remind me to give Randy credit for the term.

¹ Not apocryphal. I actually crashed Gould's real-time OS that way sometime in the 80's.

## Posted at 07:53 in category /2004conferences [permalink] [top]