On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> On Sat, Nov 25, 2017 at 6:00 AM, bartc <b...@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. -- https://mail.python.org/mailman/listinfo/python-list
