On Tuesday, December 10, 2002, at 07:59 AM, Ron Jeffries wrote:
> The rule in XP is to test everything that could possibly break.
> Therefore if things could break in integration or in the system, they
> must be tested.
I'd like to suggest that this slogan is another way of saying "test
that every case you thought of has been implemented as you intended".
Put that way, it's kind of mundane. And, for novices to test-first
design, I suspect it shifts the attention away from the "design" to the
"test". I think the design is the cool part. The design consists of
thinking of those cases worth thinking of, and deciding what should be
intended in those cases.
Let me give an example.
My time-tracking program has the notion of 'a job' in its domain model.
One of my jobs is 'stqe', for my magazine editing. When I start
editing, I start the 'stqe' job. When I start doing something else, I
pause it. At the end of the day, I stop work, and a new record of how
much I did for STQE that day gets saved.
I'm just now finding a need to be able to forget jobs. There are some
- can you really forget a job?
- what happens if you try to forget a job that doesn't exist?
What's more interesting are the less obvious tests:
- what happens to old records when you forget the job they record time
(answer: they're still there)
- can you create a job with the same name as the one you forgot?
- You can summarize the amount of time spent on a job. What happens if
the old version of the job and the new version of the job have
(tentative answer: you get a summary that includes both versions.
of dubious, but it's not likely to happen much and I'm sort of
unclear about what
else you could do. However, let's modify the previous answer to say
can create a job with the same name as a now-deleted one, but you'll
you've just done that. If you don't like that, undo and pick a
different name, or
delete the old records. Maybe there should be a way to rename old
- What happens if you try to forget a job that's currently accumulating
(answer: I believe you could actually get away with that, sort of the
way you can
delete an open file in Unix and the program that has it open doesn't
it's not something a normal person would do, so it's best to throw
Probably less work that way, since the test for the case where you
would be more complicated, and I think I'd have to test it.
Consulting, training, contracting, and research
Focused on the intersection of testing, programming, and design
"Act always so as to increase the number of choices." -- Heinz von