On Sat, Nov 25, 2017 at 6:00 AM, bartc <b...@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. -- https://mail.python.org/mailman/listinfo/python-list
