connect four (game)

[Ian Kelly]

On Sat, Nov 25, 2017 at 6:00 AM, bartc <bc at freeuk.com> wrote:
> Where are your unittests for these unittests?

Taking this question more seriously than it deserves: the tests for
the unittest module itself are at
https://hg.python.org/cpython/file/tip/Lib/unittest/test. Yes,
unittest has tests of itself.

As for tests of the tests, that's getting a bit absurd, don't you
think? Then we'd have to write tests of the tests of the tests. And
then those tests would need tests. It's turtles all the way down.

No, the point of having unit tests is to build confidence that the
code in question works correctly. It's *possible* that the code is
broken, and that the test is also broken in a way that hides the
brokenness of the code, but this is much less likely than the case
where just the code is broken. This is also the reason why the
philosophy of test-drive development stipulates that one should write
the test *first*, run it and watch it fail (this ensures that the test
is actually testing *something*) and then and only then write the code
to make the test pass.

> Or is this kind of code immune from testing?

It is the production code, not the test code, that we wish to have
confidence in.

> Actually I've no idea what these tests are supposed to prove. They are to do
> with one class called 'infinity', which is never used in the rest of the
> program apart from one line.

As I stated in my earlier reply, I just started at the top of the file
and wrote some tests. I didn't do anything for the rest of the program
because I was merely trying to demonstrate the technique, not write
hundreds of lines of tests for the OP.

> I established that within a few seconds, and I would concentrate on what
> 'infinity' is actually for, rather than go to considerable lengths to test a
> class that may not actually be needed.

If the class is used, then it's needed. There is a concept in software
testing called "code coverage". This represents the idea that every
statement in a program should be exercised at least once by the tests.
This is one of the reasons why much software testing focuses on unit
testing: if we break the program apart into units, and we thoroughly
test each unit, then we should end up with complete coverage of the
program as a whole.

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

"Seems to run" and "works correctly" are very different things.