Temporal Tables support for InMemoryDatabase

[mhoerandner]

Temporal Tables support for InMemoryDatabase

I' m using InMemoryDatabase for testing purposes (e.g. integration tests) in EF Core 6.0 and was wondering if there is any support for temporal tables?

Specifically, I have an integration test in which some rows of a table are updated several times. At the end I have to count the different column values of a specific entity.

Something like this:

public Task<int> CountAnyColumnsDifferentValues(int id)
    => DbContext.AnyTable
          .TemporalBetween(AnyDate, AnyOtherDate)
          .Where(t=> t.Id == id)
          .Select(t=> t.AnyColumn)
          .Distinct()
          .CountAsync();

Unfortunately the method always returns 1, as if there is no real implementation for temporal tables in InMemoryDatabase?

[smitpatel]

InMemory database is not a SqlServer database. There is no table (let alone temporal) in InMemory.

[roji]

@mhoerandner InMemory is specifically not about integration testing, but rather unit testing. For integration testing, you'll have to test against SQL Server - we have some docs being prepared with guidelines on how to do that.

InMemory does not behave like SQL Server (e.g. temporal tables, transactions) and it isn't possible to make it do that.

[mhoerandner]

@mhoerandner InMemory is specifically not about integration testing, but rather unit testing. For integration testing, you'll have to test against SQL Server - we have some docs being prepared with guidelines on how to do that.

InMemory does not behave like SQL Server (e.g. temporal tables, transactions) and it isn't possible to make it do that.

Thanks for the clarification. I could see from your PR3539 that you clearly differentiate between end-to-end and integration testing. In addition, your "recommendation" about using in-memory for testing has changed from "... can be useful..." to "... is discouraged".

So far I thought a fake database like in-memory would be well suited for my tests (end-to-end tests via WebApplicationFactory) because it is lightweight (e.g. no SQL server required on the build server) and for my previous (very simple) use cases it was sufficient.

Anyway, now I know and will use SQL Server for testing as well.
Thank you very much.