I think you miss the point. With a lot of code once you've mocked out all the dependencies you're not left with anything to test apart from assert derp == derp.

> you're not left with anything to test

Is this really that common? Maybe I'm out of touch, but I find it hard to imagine much code that just strings calls to dependencies together and has none of its own behaviour. Surely decisions are being made based on the dependencies behaviour? Isn't that worth unit testing?

Yes. Most CRUD apps are like this almost by definition.

It's more common for domain logic to be fairly simple and smeared across multiple systems and languages, though - e.g. some is in SQL, some is in a separate microservices, some is in module A and some is in module B and the bugs that are almost universally centered around the interactions between these systems rather than what the units do individually.

In either case unit tests end up being mimetic: assert derp == derp.

I worked with a lot of code like that. The decisions made on dependencies were trivial. Bugs happened when dependency answered with something we did not expected. Or when we send away wrong data (not knowing parameter X is mandatory when Y equals Z sort of thing).

Meanwhile, all those mocks were just clutter.

Integration tests made a whole lot of sense. Mocks did not.

I was going to write almost this same comment.

It felt like the author wanted to test all of their dependencies in their unit tests, like that was the part of the system they didn’t trust. They don’t seem to value testing that their code functions as intended given expected behaviour of the dependencies.

We rarely write unit tests because we are worried about missing an edge case while writing the code. It's often faster to manually test than write the automated case.

We write tests because we need a specification that lives past that moment in time. We also write tests because other parts of the system change because business requirements change in other parts of the system, and the necessary conversation doesn't happen.

I trust what the system does on July 9, 2023. I don't trust what the system will do on July 9, 2024. How do I guard against that?

> When writing unit tests I mock all the dependencies

I dislike this approach because whenever any of those dependencies change, I need to change all mocks. I prefer designing my code in such a way that dependencies can be easily pulled into a test instead of mocking. It may be more work upfront but pays off in the future. Instead of spending the time to write and maintain mocks, spend the time to ensure dependencies can be pulled into a test.