It's mostly a culture issue. Mocking components is a code smell. You should aim to have the implementation sufficiently self-contained and test these modules end-to-end. Some behaviors cannot be controlled and should not be abstracted away in some more exotic cases, like Environment.TickCount64-based cache expiration, in which case you should reproduce the actual environment.

The goal of the tests is to answer the question "if the pipeline is green, does it give us confidence it will work exactly as intended in production?". Mocks work against this goal.

Especially nowadays when writing tests is dirt cheap because LLMs can often get them right at the first try, there is little reason to avoid approaching this problem without prioritizing sanity over following stupid cargo cult that should have died a decade ago.

It seemed really encouraged in early Java. I think C# picked it up more to support mocking for unit testing.

The Go approach is a breath of fresh air when it comes to mocking and testing.

It's a cultural thing. I've seen code bases where every class was an FooImpl and had an associated FooIf, all in name of decoupling and mocking. Though it may be a trend that's dying down.