Code correctness, and testing strategies

[Duncan Booth]

David <wizzardx at gmail.com> 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.