Well, unit testing is only really efficient at finding certain kinds of bugs. Its good at protecting your core framework / system from breaking changes to its API, e.g. an engineer changing the result of a null being passed into a function. However, against the "I never expected anyone to do that" type of bugs, its next to useless. Only beta testing will save you there.
FTA: "YOUR PROGRAM IS NOT GOING TO BE USED BY OTHER PROGRAMS, it's going to be used by people"
A lot of programs are, in fact, used by other programs. Such programs are generally called libraries, and unit testing can be exceptionally useful for avoiding regressions in them. When testing a library, you can't really get around writing code, so why not check that code in so you don't have to write it again?
I used to work in QA and have been a proponent of unit testing generally, but I tend to agree to some extent. You can't see your blind spots, by definition, so you need really clever & devious testers to do the oddball test cases that you never think of. If you can find someone really good at ad hoc testing they can be quite efficient. Such people are hard to find.
But I also think that certain automated frameworks/tests make life easier for everyone, if they're managed well. At a minimum, they can serve as a sort of de facto specification in cases where the system lacks adequate documentation (which is the case more often than we might like.) And as others have mentioned, unit tests serve a dual role. Even if they're not great at finding new bugs, they have some value as regression tests.
I agree. The first time when I read about unit testing, I was amazed: This will find bugs!
But will it? No, I do JavaScript development and unit testing just check the output of the functions. Most of the time, all I do is DOM manipulation, function returns special values, problems like Ajax.
