In my experience, honestly the advantages of a unit testing suite are extremely minimal depending on your integration test runtime.

However, they're a good tool if for example you're working with a Big Data system, where an end to end integration test will necessarily take an extraordinary amount of time.

For my first job out of school in Apache Spark they were absolutely brilliant. For my current codebase? Not so much.

However, TDD just reduces the number of mistakes I make by an umpteenth amount.

Just because it breaks my code up into extremely short subroutines so I screw up less. Plus writing the unit test itself is a brilliant way to "measure twice, cut once."

I disagree that most tests should be integration tests. He seems to dismiss them in the article because of his experience with diminishing returns with test coverage and tests that test implementation details which basically means the tests aren’t made correctly and/or targeted at the right areas. He also seems to dismiss the pyramid rather quickly without giving a good reason against it (unit tests are quicker to run and cheaper to implement). This is not to say we should ignore integration tests entirely (or e2e tests for that matter), just that a shift to the traditional guidance is still valid.

It wasn't a direct quote, but an idea I've heard repeated many times.

And integration tests are nice, but the idea of testing small units was that every branch in the code under test doubles the number of possible execution paths, so tmit becomes harder and harder to test every path.

So we should branch less, I guess. His parts about "define errors put of existence" and writing more general code with fewer obscure details would probably help.