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

Sun, 21 Aug 2005

Video

At Agile2005, Josh Kerievsky gave an invited talk. He advocated using what I guess you could call computer-aided instruction. That was partly inspired by the amount of time his coaches spend re-covering old ground and partly by what he's seen at the North American Simulation and Gaming Conferences. (That conference has been on my list for years - because of Josh - but to my shame I've yet to go.)

One of the things he pointed out is that instructional videos are now much much easier to create and distribute. In his talk, I resolved to produce one about using Fit in a test-first style. James Shore apparently also resolved to create one, and he did. It's a slide show explanation, rather than a demo, but I thought the use of animation got ideas across in a much tighter and memorable way than text+pictures could have.

It's on NUnitAsp, in which I have absolutely no interest. But now I know something about it, and I'm glad.

## Posted at 10:06 in category /misc [permalink] [top]

Flow-style vs. declarative-style Fit fixtures

Jim Shore has a note about the dangers of flow-style Fit fixtures (ActionFixture, DoFixture, etc.). One of the dangers has been known for a while in the pure testing world (Fit is not the first tool to use a tabular format for tests): it's that the temptation to add programming language constructs is strong, and the resulting programming languages are usually bad ones.

But the more novel point is that flow-style fixtures divert attention from the essence of what is to be programmed (typically a business rule). By doing so, they stop team learning short. There's no question but that business experts like to think in flow style: do this, see that, do this, see that... However, the point of team communication is to build a group understanding of the domain, problem to be solved, and good solution. It is not to draw forth some existing solution buried in the business expert's head and shoot it across to the technical side.

Building that group understanding means building a way of talking to each other that lets the group make progress. Just as programmers should not stop with their first design, but continue to work the code in response to stories, the team should not stop with the first way of notating tests. They should shape useful abstractions.

To my mind, that's especially important because I believe that the story of a project should partly be a story of how the business expert came to understand more deeply the domain or what people need to do within it. A project in which that doesn't happen is a failure. Sticking with the first and easiest way of describing tests is a way to fail.

I'm only a little bit bold in saying that skittishness about flow fixtures is an emerging consensus in the Fit world. Which is not to say that you should never use them. (And, if you do, you ought to be using the DoFixture.)

## Posted at 09:52 in category /fit [permalink] [top]

Capture/replay below the GUI

What with this whole test-first thing, some people's attention has drifted away from capture/replay GUI testing tools. I think that's good. But I was reminded today of an oldish article from Mark Silverstein on doing capture below the GUI (pdf). It relies on a clear separation between GUI and guts, with the GUI talking to the guts using the Command pattern.

If you're going to do capture, that seems the way to do it, especially since it's yet another way to encourage layering. If - as is extremely likely - the resulting scripts will be read by humans, not just executed, it might also encourage good (business-facing) names for the guts API.

## Posted at 09:52 in category /testing [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.

 

Syndication

 

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

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

 

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

 

Join!

Agile Alliance Logo