If a particular unit test costs you more to write than it saves you in bugs, don't write it. And if it starts costing more in maintenance than it saves in confidence, get rid of it. There's a fair bit of cargo culting going on about how much to test - in my experience, it's not worth testing getters/setters, it's not worth testing simple "if this then set these variables" logic, and it's not worth unit testing database or external calls (you should have some integration tests for them though).

It is very much worth testing tricky cases like a parser, or a bit-level decoder, or complicated algorithms. I just recently got up to 100% code coverage on a UTF-8 decoder I'd written. I found about a dozen bugs in the process. They were silly things, like leaving a digit off a hex constant, but they rippled throughout the decoder so that the results were completely wrong. If I'd just included that in another library without testing, it'd make the dependent library subtly wrong too, and I'd never hear about it until users started complaining, and they'd waste hours trying to find bugs in their code that are really bugs in mine.

I'll also mention one other thing: the point of unit testing isn't to find bugs, it's to give you enough confidence in your code that you can freely change it. The real cost of bugs isn't that one erroneous event that customers will probably never notice, it's that the fear of that one unpredictable event makes management (which is sometimes you, if it's your startup) say "It works. Don't touch it, because you'll break it" and never improve the software. That's how you get shitty software that you can't fix.

I think it's fair to say that integration tests (make sure that the functionality works) are useful; period. Not knowing whether your app is going to work when you push it is not fun.

From a maintenance perspective and assuming that a problem will show up in integration testing or via a bug report, further testing is only really useful to the extent that it lets you debug a failure faster. However that acceleration is a tradeoff against the time taken to write the tests in the first place - ergo: is it really worth it?

I personally don't think the real win from tests is in saving debugging time. I have found it's in making it quicker to write code. I know that sounds crazy as most people view tests as overhead but I view them as development tools.

The key to them being useful though is writing them before you write the code. If you write them afterwards you will have already verified the code in an ad-hoc fashion and the tests are pure overhead. If you write them before they do the verification for you.

I'm coding in Rails and I've found the outside-in approach to development: write the six line Cucumber integration test and then write the RSpec expectations for the object; act as a verified to-do list and make my development far more efficient and robust.

I'm sure that other developers with better focus than I might not get the same benefit but I find it tremendously useful to immediately list down all of the edge cases and general behaviour that a piece of code should exhibit and then keep coding till growl glows green. I trade the time that I'd otherwise spend faffing around in a browser or a debugger for writing tests instead.

It's a bonus that all of those tests then ensure ongoing integrity, the real win is that tests stop me from wandering around the trail and keep me knocking things off in the order that they need to be done. [Caveat: it has taken me months and months to come up to speed on how to write tests well] (great article btw Bill)