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, 13 Mar 2003

The conduit metaphor (continued)

My earlier note looking at test-driven design in terms of the conduit metaphor has gotten more response than I expected.

Tim Van Tongeren writes:

You might like some of these other models, which take into consideration noise, decoding, and feedback.

Glenn Vanderburg wrote two blog entries riffing on it (here and here). Here are a couple of quotes to give you a flavor:

But the problem there, I believe, is largely that people have a hard time communicating about abstract things... the problem is that there's almost no feedback about whether you really understand what's being said. I've been completely confused and at the same time absolutely convinced that I understood everything...

When people have those same discussions in the context of code -- working code -- communication changes. It may seem strange to say this about software, but code is concrete. It's unambiguous. It grounds our discussions in a reality, and it's a terrific aid to effective communication and understanding.... It's no wonder that, in many test-first teams, design debates are frequently carried out through unit tests.

...

Part of the strength of XP and many other agile methods is that they don't address the communication per se; instead, they address the context in which it occurs. They strive to make communication less formal, more frequent, more concrete, more serendipitous, and (tellingly, I think) more redundant. The key is understanding that people want to communicate, and we're good at it, if the barriers are low enough.

I find the point about abstraction interesting. It's close to one I often make. I refer to myself as a "recovering abstractionist", so I tend to be dogged about insisting on concreteness and examples. (There are people who roll their eyes when I get on the topic.)

And yet... It seems to me that tests aren't entirely concrete. They're somewhere usefully between concrete and abstract. I don't know how to talk about this, exactly - maybe the point is too abstract. But if, as I said earlier, part of the purpose of tests is to provoke a programmer to write the right program, part of the craft of test-writing is to pitch the test at the right level of abstraction (or, if you don't believe in levels of abstraction, use the right words) to help the programmer think the right thoughts and take the right actions.

## Posted at 20:14 in category /agile [permalink] [top]

Shy code, adventurous testers

Andy and Dave have put more of their IEEE Software articles up on Pragmatic Programmer.com. I quite like The Art of Enbugging (pdf) with its metaphor of "shy code".

If, as I believe, the decade-or-more-long swing away from testers who can code is reversing, we have to confront the fact that way too many testers-who-can-code code badly. Testers should read Dave and Andy's book, The Pragmatic Programmer.

In return, programmers should read Cem, James, and Bret's book, Lessons Learned in Software Testing.

## Posted at 14:12 in category /testing [permalink] [top]