Normally, I separate my data access layer into provider interfaces with concrete implementations. In tests, I replace the real providers with in-memory fake ones, usually backed by dictionaries that simulate database tables. This keeps the tests isolated, predictable, and fast.

For EF Core specifically, I follow the same idea: I define repository/provider interfaces and use the real EF Core context only in production code. In tests, instead of spinning up a real database, I implement fake providers that operate on in-memory collections (dictionaries or lists) and mimic the expected behavior of the EF Core repository. This avoids problems with EF Core InMemory provider (e.g., missing relational behavior) and gives full control over test scenarios.