Care to comment on your experience with larger code bases? The content of your post seems short-sighted, and there's an exponential function of complexity increase as LOC and developer headcount both go up.
You're right people pay for features, but lagging a little at the beginning to establish good TDD culture pays off in spades later on. Shipping product is something you have to do continuously, and you arguably create more value as time goes on, so ensuring you can continue to ship product in a timely manner is a great thing for organizations.
I'm not the original poster, but I find that integration tests have a far larger payoff than unit tests, in general. A good release process that tests differences in behavior between a test system and the current version of the service in production is also valuable.
Being able to test that the whole system works as intended gives a better return on investment, in my experience, than testing small bits in isolation. The errors are, often as not, in the glue between the small bits.
The main advantage I've found from testing little bits in isolation is that it tells you a lot more about where exactly the bug is. However, there's no reason why you need to write them in advance to get this benefit.
The general workflow I've grown fond of is to write mostly higher-level tests that test the system as a whole, and then only write fiddly unit tests when there actually is a bug to fix. Those unit tests then stick around, but I don't feel bad about blowing them away without replacing them if the thing being tested changes significantly enough to make them useless.
Unit-tests work great for us for testing some well isolated pieces of complex logic with a simple API (e.g. algorithmic stuff). But we don't unit-test things simple like getters or setters or code that is glue between components and just delegates real work to some other components. For this, we do functional / integration testing and it plays well.
I've worked on quite a few different large code bases. I agree with the author 100%. Tests are a tool. They are a particularly useful one, but they are just a tool. Unit tests are significantly less useful than TDD folks would have you believe when compared to things like integration tests. And integration tests are vastly more costly than what TDD folks would have you believe. Personally, I much prefer gold file tests with manual inspection when it comes to test automation. I've seen large compiler projects that get by pretty far with just that. Never mind things that make no sense to test: Like "Is this game fun?"
The key, to me, is determining what needs to be tested. That doesn't change with larger code bases. Note that I didn't say that tests were pointless or that you shouldn't write tests. That's incredibly shortsighted.
Originally I was going to title this "Tests are overrated" but that both seemed like linkbait and distorts my actual opinion.
I've been on projects where they tested to make sure that certain values were unique in the database and I couldn't help but think they: didn't understand the framework; didn't understand what tests are meant to do; didn't understand database key constraints; or all of the above.
Tests have their place. But they are a means, not an end. And I see a lot of people confusing them for the end.
But, again, I don't dislike tests. I just dislike what I perceive to be a current overemphasis.
You're right people pay for features, but lagging a little at the beginning to establish good TDD culture pays off in spades later on. Shipping product is something you have to do continuously, and you arguably create more value as time goes on, so ensuring you can continue to ship product in a timely manner is a great thing for organizations.