connect four (game)

bartc bc at freeuk.com
Sun Nov 26 09:11:50 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