Sean O'Dell wrote:
> 
> I've NEVER been able to anticipate errors that I couldn't anticipate (think), 
> so writing a bunch of unit tests in advance never found me a single bug.  
> They super rarely re-occur, so writing unit tests when debugging has never 
> helped me there either.


I believe the purpose of unit testing is to ensure correct program 
behavior, not to trap bugs per se.  The tests tell you that each of your 
methods and objects will Do The Right Thing when given appropriate 
input, and/or complain when given junk.

They also help indicate when a design path may not be a good choice, or 
when refactoring may be called for.

If you find yourself with a method that is hard to test, then perhaps 
the method needs a rethink.

A big value of unit testing comes when your code is several thousand 
lines and you find you need to start shifting  things around or tweaking 
the logic someplace.  If the test are reasonably thorough then you find 
right away where something is fragile rather than having to wait until 
some unique or unanticipated runtime condition.

I understand the sentiment of not seeing much gain for all the extra 
test writing early on, but I've been bitten enough by complex code 
interaction once a project goes past a certain size that I've constantly 
regretted not doing the tests to begin with.

As with duck typing, it's not for everyone, and there's no reason anyone 
should be brow-beaten into following one or another style of design and 
development.  Just another option, TMTOWTDI, YMMV, and so.

James