Example First Programming

I always felt, that we it would be good to focus more on examples. How about ExampleOrientedProgramming? ? You give an example for a start object and one for the goal and name the transition between them. If the rest cannot be found automatically by the machine, write the appropriate method or change an already existing one. That's it. Tests don't need more than this. One nice thing about examples is, that they can easily be composed to form another example. Tests can't.

-- MarkusGaelli

Moved from UnitInUnitTestIsntTheUnitYouAreThinkingOf?

I think of these Unit Thingies as examples. They share many properties with declarations, but there is an implication of formality in the term "declaration" that does not exist for examples. Also, the tests tend to be imperative, not declarative, in nature. So I would say that XP is a form of ExampleFirstProgramming.

The sequence is something like this: We think we need something, so we specify it by example. Like all good examples, this one is executable. We then write some code to test the example ;-). Once it seems to work, we add the example to a regression test suite (and name it a unit test).

This is an interesting twist on a technique I've used successfully for customer support: I've frequently found I can explain how to use an interface by providing an example derived from a test.

-- DaveWhipp.