i think some developers put too much stock in unit testing and it gives them (and their managers, customers, and co-workers) a false sense of security. they end up wasting time and not really preventing as many bugs as they think it will. application logic changes and they have to write twice as much code to change the application and all of the tests that depended on that logic.
writing a regression test for a complicated routine or library is one thing, but writing a test for every method of a class just for the warm fuzzy of their test framework telling them they have 100% coverage is silly.
Unit tests may be overrated, but writing them certainly isn't.
I've seen so many programmers start writing so much better code after adding the criterium "it has to be testable".
BTW, the killer bugs are usually not in the "complicated routine". They are more often in the simple things programmers like to think they can do so perfectly that they don't need to write tests for it. I have found many a bug in the most simple one line functions I never bothered to test.
I said this to my coworker yesterday: the funny thing about code is that the more testable it is, the less it actually needs to be tested. (I specifically meant unit tested, because well factored code is easier to reason about, etc.)
I totally agree, who tests everything has just missed the point. I write tests for critical parts of a software that have an high risk to fail somehow (a DAO or Billing implementation, for example).
It's not all or nothing proposition as your opening sentence perceive to be.
Just wait until you need to actually write an automation test and dealt with code/developers who happen to say "well, it's hard to do that now since we have tightly written code".
Sometimes it feels like unit tests are simply there to replicate the mechanisms of a strongly typed language. Makes you wonder why they chose a dynamic language in the first place...
i think some developers put too much stock in unit testing and it gives them (and their managers, customers, and co-workers) a false sense of security. they end up wasting time and not really preventing as many bugs as they think it will. application logic changes and they have to write twice as much code to change the application and all of the tests that depended on that logic.
writing a regression test for a complicated routine or library is one thing, but writing a test for every method of a class just for the warm fuzzy of their test framework telling them they have 100% coverage is silly.