On 26/11/2017 14:23, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 1:11 AM, bartc <b...@freeuk.com> wrote: >> 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.) > > Everyone in the world has the same problem, yet many of us manage to > write useful tests. I wonder whether you're somehow special in that > testing fundamentally doesn't work for you, or that you actually don't > need to write tests. Or maybe tests would still be useful for you too. > Could go either way.
Testing everything comprehensively just wouldn't be useful for me who works on whole applications, whole concepts, not just a handful of functions with well-defined inputs and outputs. And even then, it might work perfectly, but be too slow, or they take up too much space. Take one example of a small program I've mentioned in the past, a jpeg decoder. I had to port this into several languages (one of which was Python actually). It was hard because I didn't know how it was meant to work. Only as a whole when the input is a .jpeg file, and the output might be a .ppm file that ought to look like the one produced by a working program, or the original jpeg displayed by a working viewer. (Which is not possible in all applications.) How to do an automatic test? Directly doing a binary compare on the output doesn't work because in jpeg, there can be differences of +/- 1 bit in the results. And even if the test detected a mismatch, then what? I now know there is a problem, but I could figure that out by looking at the output! And actually, after it ostensibly worked, there WAS a minor problem: some types of images exhibited excessive chroma noise around sharp transitions. The problem was traced to two lines that were in the wrong order (in the original program). I can't see how unit tests can have helped in any way at all, and it would probably have taken much longer. And THIS was a small, well-defined task which had already been written. >> 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. > > So there was something else wrong with the chip. I'm not sure what > your point is. The extensive testing was like unit testing, but needed to be even more thorough because of the commitment involved. It failed to spot a problem. And actually I had a similar problem with a new car. I took it back to the dealer, and they said they plugged the on-board computer into their analyser, which did all sorts of tests and said there was nothing wrong with it. But there was, and the problem has persisted for a decade [to do with the central locking]. I'm saying you can rely too much on these tests, and waste too much time on them. Perhaps that is a necessity in a large organisation or in a large team, where there is a leader to look at the big picture. It doesn't work for individuals working on one project. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
