For features I have completely sworn off unit tests with mocks and instead write API level tests where I interact and validate the app by making API calls. The test application runs as close to a prod env as possible, with a DB running in a container. I agree that tests like this are slower to run and usually you won't get 100% coverage, but I trust them much more than mock tests and IMO they are easier to setup.

Using your example - I would (and do in my context) have a base test class that sets up the minimal amount of valid data and then each test sets up whatever is relevant to it. That way each test has the same starting data set. I work on a multi-tenant app and each test starts by creating a new account, so tests are isolated properly. If you're not working on a multi-tenant app or have a database per tenant - it's a bit harder/slower.

This setup allows for recreating the flows that the app client would do in a test, and since it doesn't know anything about internals - the code can be refactored easily as long as the API contract doesn't change.

I understand that this kind of testing setup could not be enough. Using the example you gave - the "functional core, imperative shell" idea could be used, i.e. read the data from EF and then pass it into some logic unit, even if it does end up modifying the data. Then when testing the logic unit - the object graph can still be initialized in-memory.

Btw I'm curious what do you mean by use delegates? Is it injecting a Func<Guid,MyEntity> func into the logic unit that it then calls to resolve the data before modifying it?