connect four (game)

[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