On every large codebase I’ve worked on , updating a low level function has required more work updating the tests than updating the application using it.

Unit tests have a place, but IME are overused as a crutch to avoid writing useful bigger tests which require knowing what your app does rather than just your function.

> Integration test are slow/expensive to run compared to unit tests and reduce your iteration speed.

My unit tests might take under a second to run but they’re not the ones (IME) that fail when you’re writing code. Meanwhile, integration tests _will_ find regressions in your imperfect code when you change it. I currently use c# with containers and there’s a startup time but my integration tests still run quickly enough that I can run them 10s or hundreds of times a day very comfortably.

> If you’re doing a lot of mocking then your design is not good.

This is the “you’re holding it wrong” argument. I’ve never seen a heavily unit tested codebase that didn’t either suffer from massive mocking or wasn’t decomposed into such small blocks that they were illogically small and the mental map of the project was like drawing with sand - completely untenable.

> And only public interfaces should have testing.

This is the smoking gun in your comment - I actually disagree and think you should infer this. Services (or whatever you call them) should be tested, and low level functionality should be tested but the stuff in the middle is where you spend 80% of your time and get 10% of the benefit

> Unit tests let you change code fearlessly with instant feedback.

Sure they can add confidence in making changes. But I've seen they can also give you false confidence.

As I said, I can still assemble your perfect Lego bricks together wrong. And you can still change the public behavior while keeping your unit tests passing fine. I've seen both happen in practice.

That's why I think integration tests (or whatever you want to call them) give you more bang for your buck. They give you even greater confidence that your stuff works, and generally you can cover a lot more with far fewer tests so improves ROI.

The tradeoff is that it can take a bit longer to run.

> If you’re doing a lot of mocking then your design is not good.

If my app needs to talk to a database, store things in object store, send some messages in a message queue and so on, I can't not mock those things away if I'm to write unit tests.