connect four (game)

nospam.nospam.bartc bc at freeuk.com
Sat Nov 25 21:11:00 EST 2017


On 25/11/2017 16:07, Michael Torrie wrote:
> On 11/25/2017 06:00 AM, bartc wrote:
>> And there's a quite lot left of the rest of the program to worry about too!
>>
>> If you add 'window()' at the end of the program, then it seems to run on
>> Python 3. I'd play around with it first before thinking up strategies
>> for testing it.
>
> Actually, no.  Unit testing ideally should be done for each and every
> class as they are being written (before they are written in fact), no
> matter how small and trivial the class.  That way as you compose larger
> and larger units of code, the chances of things being right is greater
> compared to doing it the other way around.

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.)

I've also found that many of the bugs that do appear, also do so in ways you
never anticipated. Or in circumstances you would never have thought of.

(I've always thought that programming is a bit like creating new laws. The same
 laws need to work for everyone and in any circumstances, but no one can
foresee everything, and laws need to be tweaked and added to. Perhaps unit
tests can apply there too...)

> You may argue that testing doesn't matter for his small game, written
> for his own education and amusement.  The fact is that software in
> general is of abysmal quality across the boards, and promoting a habit
> of unit testing is good, even for trivial, home-grown stuff.

I thought people were being hard on the OP.

As for testing, I remember in a company I worked in, a complicated circuit was
submitted to a company that would put it into a mass-produced chip. This
company did massive numbers of emulated tests shown on a huge printout that
showed that all combinations of inputs and outputs worked exactly as intended.

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.

--
bartc




More information about the Python-list mailing list