connect four (game)

Ian Kelly ian.g.kelly at gmail.com
Sat Nov 25 12:16:51 EST 2017


On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Sat, Nov 25, 2017 at 6:00 AM, bartc <bc at freeuk.com> wrote:
>>> Where are your unittests for these unittests?
>>
>> 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.
>
> To be fair, TDD doesn't actually prove that the test isn't broken. It
> only protects you against one class of error: tests that actually
> aren't testing anything. Proponents of TDD will argue that this class
> of error is quite common; true or not, it's still only one particular
> kind of failure. It's definitely possible for tests to be wrong in
> such a way that they don't detect faulty code.
>
> So what do we do? WE TEST BY HAND. Ultimately, unit testing is a tool,
> not a magic wand. It's up to us to actually put it to use to improve
> code quality.

Certainly. I wasn't trying to advocate for TDD here, which I don't
even practice regularly myself.



More information about the Python-list mailing list