I think its more likely that the author _inherited_ some lame tests and this has coloured his opinion somewhat.

Indeed. The whole essay boils down to "bad unit tests are useless, therefore unit testing isn't worth bothering with".

More like "bad unit tests are useless, good and useful unit tests are hard and take a significant chunk of time, therefore weigh the costs vs the benefits before deciding whether to bother or not"

Hm. Before deciding that good and useful unit tests are too expensive, spend a week or three doing live support of poorly reported and hard to reproduce issues where the numbers were slightly out or the result came back ten seconds later than it should, one time. that will change your perspective on what's hard and what's not. And possibly damage your will to live.

Indeed. If you think good unit tests are time-consuming, try debugging code with lots of subtle bugs in it.

If the bugs are that subtle what makes you think you're unit tests are comprehensive enough to catch them? The hardest bugs to debug are the types that show only on high latency networks and only when dealing with files bigger than 2GB and only after the app has been running for at least 50 hours. Those are also the type of bugs which are almost impossible to write unit tests for.

I'm not arguing against unit tests, they definitely have a time and a place. I'm just not convinced that they are an easy and instant cure for all your hardest bugs.

Unit tests may leave you with remaining subtle bugs. This is better than having both subtle and obvious bugs. Obvious under test, e.g. "the class returns null when it should return object y", which can have subtle and easy-to-miss symptoms in a production system