From: Daniel <notdanielt3@...>
Date: 2001-12-17T02:35:37+09:00
Subject: [ruby-talk:28698] Re: test-first

This is a single general response to the replies written by Mr.
Jeffries, Martin, and Roth...

Yes it is possible to write a test to see if your collision detection
algorithm works but that means nothing. What is important to the user
is that the ball bounced off the paddle. Just because I have a working
collision detection algorithm doesn't mean the ball on the screen will
bounce correctly.

Mr. Martin claims that XP "advocates writing tests that are so simple
that they can be eyeballed to work." I say that all your functions
should be written that way. In which case, the tests are superfluous
because we can just look at the function and know it works. (Assuming,
of course, that all the functions this one calls work. :-)

In video games, the only test that matters is, "Does the producer like
the result?" The answer to that changes with the wind.

I've had producers tell me they hate a particluar part of the program,
then in the next internal release, tell me they really like the changes
I made. When, in fact, I made no changes to that part of the program at
all.

I've had functional specs that have been in forced for 5 months
straight, but then thrown away in the last week of the production cycle
(forcing us to re-write whole sections of code) because some higher up,
who finally got around to looking at the program, didn't like the
result.

In my work, there are no business rules to test against. :-(

Mr. Roth admits that:

>Existing GUI testing tools are both expensive and fragile;
>everyone agrees something better is urgently needed, but nobody
>has done it yet - as far as I know.

The reason they are expensive and fragile is because they are *hard* to
write. I want to work on factoring our engine so that we can at least
automate the input so the tester need just sit back and watch the
screen to ensure that things go as planned. This requires seeding the
random number generator and generating mouse and key down events at the
correct times based on information in scripts, and should be fairly
trivial, but will actually test very little of the application's
functionality. It should come in handy for regression testing though.

Of course, it's not likely to happen. Management isn't willing to let
anyone touch the engine, despite the fact that all the programmers
agree that it is bloated, fragile and generally hard to work with.
After all, we've used the engine for 10's of products now and that
means that it "works" despite the fact that we spend half our debug
time tracking down some temporial dependency in the engine that no one
knew about. (Documentation consists of a 4 hour overview lecture when
one first starts working for the company. :-(