connect four (game)

[nospam.nospam.bartc]

On 26/11/2017 14:23, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:11 AM, bartc <bc at freeuk.com> wrote:
>> The way I write code isn't incrementally top down or bottom up. It's
>> backwards and forwards. Feedback from different parts means the thing
>> develops as a whole. Sometimes parts are split into distinct sections,
>> sometimes different parts are merged.
>>
>> Sometimes you realise you're on the wrong track, and sections have to be
>> redone or a different approach used, which can be done in the earlier
>> stages.
>>
>> If I had to bother with such systematic tests as you suggest, and finish and
>> sign off everything before proceeding further, then nothing would ever get
>> done. (Maybe it's viable if working from an exacting specification that
>> someone else has already worked out.)
>
> Everyone in the world has the same problem, yet many of us manage to
> write useful tests. I wonder whether you're somehow special in that
> testing fundamentally doesn't work for you, or that you actually don't
> need to write tests. Or maybe tests would still be useful for you too.
> Could go either way.

Testing everything comprehensively just wouldn't be useful for me who works on
whole applications, whole concepts, not just a handful of functions with
well-defined inputs and outputs. And even then, it might work perfectly, but be
 too slow, or they take up too much space.

Take one example of a small program I've mentioned in the past, a jpeg decoder.
 I had to port this into several languages (one of which was Python actually).

It was hard because I didn't know how it was meant to work. Only as a whole
when the input is a .jpeg file, and the output might be a .ppm file that ought
to look like the one produced by a working program, or the original jpeg
displayed by a working viewer. (Which is not possible in all applications.)

How to do an automatic test? Directly doing a binary compare on the output
doesn't work because in jpeg, there can be differences of +/- 1 bit in the
results. And even if the test detected a mismatch, then what? I now know there
is a problem, but I could figure that out by looking at the output!

And actually, after it ostensibly worked, there WAS a minor problem: some types
 of images exhibited excessive chroma noise around sharp transitions.

The problem was traced to two lines that were in the wrong order (in the
original program). I can't see how unit tests can have helped in any way at
all, and it would probably have taken much longer.

And THIS was a small, well-defined task which had already been written.

>> Except the actual chip didn't work. As for the printout, the designer took
>> it home and used it as an underlay for a new carpet. A rather expensive
>> underlay.
>
> So there was something else wrong with the chip. I'm not sure what
> your point is.

The extensive testing was like unit testing, but needed to be even more
thorough because of the commitment involved. It failed to spot a problem.

And actually I had a similar problem with a new car. I took it back to the
dealer, and they said they plugged the on-board computer into their analyser,
which did all sorts of tests and said there was nothing wrong with it. But
there was, and the problem has persisted for a decade [to do with the central
locking].

I'm saying you can rely too much on these tests, and waste too much time on
them.

Perhaps that is a necessity in a large organisation or in a large team, where
there is a leader to look at the big picture. It doesn't work for individuals
working on one project.

--
bartc