> If you're starting with TDD and unit tests, then you're doing it wrong

Source?

Please. This is just plain wrong. Integration tests also belong to TDD.

Unit tests are very focused, individual, component level tests. Suppose, I want to test my mortgage calculator logic, without bothering about caching, data storage, network IO etc. Then, unit tests are the way to go. But, if I want to test the functionality, just like an end user then Integration Tests are the way to go.

You might also use Integration tests to get your stories approved.

One might say Integration tests belong to BDD. I'll say that is just a lower level categorization. At the top, it's just TDD.

In a world of no tests, a handful of high level tests on "critical path" functionality can make a huge difference. They can also demonstrate visible wins to unconvinced stakeholders.

I don't know the OP's world, but I can vouch for starting with high level tests being a good strategy in some cases.

Generally, I agree with this statement, but my experience shows me that there's a very important exception here: if a code implements any kind of parser or compiler, unit tests are a must for that part.

In the compiler I'm working on at work the integration tests have been the most useful.

I personally agree with this approach - but it's in vogue in my experience. I liked https://kentcdodds.com/blog/write-tests