We don't really have this problem in .NET 8, we mock stuff just fine using an in-memory database provider.
But I admit my tone missed the mark. It may have been much harder to do in the past, or maybe I'm missing some nuance.
But also at this point why not just have your DbContext directly implement an interface that you can mock? Surely that must be more straightforward than adding an entire abstraction layer, that you have to extend with each new usage scenario, and without sacrificing implicit transactionality.
> We don't really have this problem in .NET 8, we mock stuff just fine using an in-memory database provider.
No, you don't. At best in-memory databases represent a test double that you can use in integration tests.
If you need to write unit tests, EF leaves you no better option than to add repositories to abstract out everything and anything involving DbContext.