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

Fri, 21 Feb 2003

Generative and elaborative tests

In the test-driven development group, John Arrizza writes:

IMO, there are two kinds of tests in TDD, both of which are heavily related to each other. The first is a speculative test, it will cause you to write code for a very small part of new functionality. The new code satisfies some small part of your spec, requirements, task, Story, etc.

The second kind of test will confirm that the code you've just added works as you expect in and around the existing functionality. It examines slightly different but related parts of the solution space that are important to you. These do not have to be comprehensive, but they do have to be relevant! You write these until your anxiety is satisfied, or as Phlip says "write tests until you're bored."

The first kind moves the design forward in an area, the second fleshes out the design in that area.

Bill Wake chimed in:

I have the same feeling - I call the first set "generative" as they drive through to generate the design, and the second set "elaborative" as they play out the theme and variations.

I think naming these two (of N) types of tests is a useful thing to do, so I intend to talk about generative and elaborative tests from now on.

## Posted at 13:37 in category /testing [permalink] [top]

Some tools for Windows switchers

I switched from Windows to Mac OS X last summer. It seems I know a lot of people who have switched too (PragDave), will switch as soon as their 17 inch TiBook arrives (Cem Kaner), or won't be able to resist forever (Mike Clark).

Back in my Unix days, I used to be quite the tinkerer. I fiddled with my environment to make it just so. When I went to Windows, I stopped doing that. I just submitted. On OS X, I'm back to spending time making myself more efficient.

Here are some thing I've done that other switchers might like. Let me know what you've done.

  • I have a 15 inch iMac, but I've migrated to using my 15 inch TiBook as my work machine. More pixels. I normally run it with a Sony SDM-X52 15 inch flat panel display as a second monitor. Having a second screen is just enormously more efficient for so many tasks. The Sony isn't the greatest display, but it's the best I could find out here in the boondocks for around $400. (I didn't want to buy sight unseen.)

    I actually have my iMac set up to the left of my TiBook, so I'm facing a semicircle of screens. It looks cool, but the iMac is just running iCal, my current todo list (in TextEdit), a program called Consistency (about which, more later), and iTunes.

  • I bought a Maxtor firewire drive as a backup device. Daily, I make a bootable disk image to it using Synchronize Pro X. I find it reassuring to know that, if my hard disk fails, I can run from the firewire disk. The Maxtor drive is a touch noisy. Synchronize Pro X is a bit pricy ($100), but I also use it to synchronize directories between the two macs.

  • I like switching programs from the keyboard, and I don't like the way the Dock does it. I always overshoot. So I bought Keyboard Maestro for $20. Option-Tab cycles you through a list of only the running programs. There are other commands to get you quickly to the finder, to quickly quit all programs, to back up if you overshoot, etc. It also lets you have N clipboards instead of just one. You can also program the keyboard to do arbitrary things. For example, when I'm in Emacs, F6 means "switch to project builder, build the debug version of the current program, and run it". That way, I can write my Ruby code in Emacs but still use the Project Builder for the things it's good for.

  • I use an Aquafied Emacs instead of the one that ships with the Mac.

## Posted at 08:08 in category /mac [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