David <[EMAIL PROTECTED]> wrote:
> Problem 2: Slows down prototyping > > In order to get a new system working, it's nice to be able to throw > together a set of modules quickly, and if that doesn't work, scrap it > and try something else. There's a rule (forget where) that your first > system will always be a prototype, regardless of intent. That's fine. It's alright to prototype without tests. The only rule is that you cannot then use any of that code in production. > Problem 3: Slows down development in general > > Having to write tests for all code takes time. Instead of eg: 10 hours > coding and say 1/2 an hour manual testing, you spend eg: 2-3 hours > writing all the tests, and 10 on the code. > You are either a very slow coder or a very poor tester: there should be a lot more than 1/2 hour testing for 10 hours coding. I would say the comparison might be 10 hours coding, 10 hours testing, then about a week tracking down the bugs which escaped testing and got out to the customers. With proper unit tests you will reduce all 3 of these numbers but especially the last one. Any bug which gets away from the programmer and is only caught further downstream costs vastly more than bugs caught during development, and not just for the programmer but everyone else who affected. You seem to think that people are suggesting you write all the tests up front: what you should be doing is interleaving design+testing+coding all together. That makes it impossible to account for test time separately as the test time is tightly mixed with other coding, what you can be sure though is that after an initial slowdown while you get used to the process your overall productivity will be higher. The first time you make a change to some code and a test which is apparently completely unrelated to the change you made breaks is the point when you realise that you have just saved yourself hours of debugging when that bug would have surfaced weeks later. > Clients, deadlines, etc require actual software, not > tests for software (that couldn't be completed on time because you > spent too much time writing tests first ;-)). Clients generally require *working* software. Unfortunately it is all too easy to ship something broken because then you can claim you completed the coding on time and any slippage gets lost in the next 5 years of maintenance. -- http://mail.python.org/mailman/listinfo/python-list
