projects are FLOODED with automated testing tools to ensure their code works. And sure enough, every bug that I submit has an "automated test" that didn't test that particular condition
THIS THIS THIS
As a software engineer (now half-suity) of twenty years, I am constantly frustrated by those newer to the profession who got caught up in the whole "Unit Tests are Sacrosanct" philosophy. I have worked with multiple engineers who value "testability" over "working".
Unit tests are convenient, a handy tool for programmers, but in my experience they have close to zero inverse correlation with the number of bugs in the programmers output. Any programmer who can think of the right cases for his unit tests is also capable of considering those same cases when writing his code - the correlation between [Experience and Ability] and number of bugs is the biggest one out there.
Know what I favour? Readability and simplicity over pointless abstractions. Functioning, working applications over "90% code coverage". Things that fail at compile-time over things that fail at run-time. And when I press these principles onto more junior devs I always get push back about how "that's old fashioned" or "that needs extra lines of code" - they seems to complete disbelieve, and then they wonder how the hell I write and manage multiple web sites in my spare time that are generally more complex and reliable than any of the commercial sites I've worked on (with one or two notable exceptions).
KISS applies to everything, and unit tests do not adhere to this principle. They have a time and a place when they start to show their value - and that time and place is when SOME of the following are true:
-] Codebase is expected to be maintained by a large team, or eventually by persons who were not involved in building it
-] Codebase will be architected by senior staff, and then maintained by more junior staff
-] Codebase may be sold to, or extended by, third parties (open source is big on this)
-] Codebase is difficult to read/pick-up and has high levels of abstraction
-] Codebase is expected to change significantly in the short or medium term
-] Team involved is junior or inexperienced in one or more significant factors (in general, language, app domain)
Outside of some of these scenarios (I may have missed some, please do comment) you should be seriously considering how much of your investment you place into Unit Tests. I have seen some companies/teams/individuals spend more time writing unit tests than they did functioning code - that's negligent in some cases. If your team had double the velocity on new features by simply writing features instead of upping levels of code coverage, your company/owners/shareholders would have twice their return on investment...