EntityFramework.Docs VS Respawn

Each release of Entity Framework Core the Microsoft engineers provide code samples. Although these code samples are great, they are not structured for learning and use in a developer’s projects. Also, there are many code samples that may not be useful to the average developer. With that said I took Microsoft code samples and structured the code in a fashion suitable for the average developer to learn from.

This is documented well for Entity Framework Core, with code samples as well, but there isn't any clear information about having a multi-tenant, multi-db approach for the token cache. The official Multi tenant Azure AD documentation does mention the token caches, but it doesn't talk about a multi-db approach.

Even from the Microsoft example, they use .HasData in their modelbuilder. MicrosoftGithubSeedExample

What have you tried? What doesn't work? The link you provided is a fairly straightforward example of the concept. Including the sample code.

Take a look at this sample project: https://github.com/dotnet/EntityFramework.Docs/tree/main/samples/core/Miscellaneous/Testing/ItemsWebApi/Tests

ImMemoryDb isnt recommended for testing as it doesnt behave as a real database. Save yourself trouble and use a real database paired with Respawn.

I come from a .NET background and in the .NET environment I used to seed the database with the necessary data on each test and then clean the database at the end of the test using the Respawn library.

This was our initial approach (using sqlite) but our migrations take a while to run and this resulted in slow tests. Using Respawn to clean the db significantly improved test performance (https://github.com/jbogard/Respawn)

Have you used something like Respwan https://github.com/jbogard/Respawn instead of creating and cleaning or deleting database every time? Not sure if it would help you. But I thought it might make your workflow little simpler. Respawn lets to restore db to a restore point.

NUnit, FluentAssertions, Moq & Respawn

You will need a separate test database purely for integration tests. You will need to reset the state of the DB every time using something like https://github.com/jbogard/Respawn. I always use the (localdb)\mssqllocal SQL instance that comes as standard with VS for dev and integration test databases.