>Paul Sheriff wrote in his article
>
>"Testing often helps you improve the quality of your code. As you think about the various scenerios that can go
>wrong, you start to add addition code to handle these scenerios. This leads to your code being more robust
>and more maintainable and user friendly".
>
>I disagree. You can't code for every conceivable issue that might arise, Trying to do so leads to your code being
>more bloated and far less maintainable.
>
>He also listed automaated testing as one possible alternative. I worked for a company that insisited that automated testing
>was the key, We spent more time writing test than we did coding. What's to say the test drivers are correct?
>
>IMHO, and my 25 years of coding experience, unti testing is key. Write small modules that do one thing, and one thing only,
>the test them to ensure they do what they were designed to do. Add them to larger pieces, then that that to ensure everything
>plays well togethere. Continue until the product is done.
>
>I'm curious about other opinions and what other techniques you guys use.

I think the type of application in question will have a significant bearing on the answer.

At one end of the scale if you are writing a one-off utility application for your own use then you won't want to spend much time writing defensive code and testing functionality.
OTOH if you are sending a man to the moon you do a *LOT* of testing.
Most applications falls somewhere in between. I've certainly worked on projects where there were more testers than programmers. But I suppose that could be a reflection on the quality of the programmers :-{