The integration tests of the last lesson replace the store with a list in memory. That’s fast and checks the pipeline, but they don’t see anything the database itself decides. In module 2.4, you built rules that only SQL Server enforces, above all this one: two bookings of the same time at the same instant must not both succeed. In this lesson, tests run against a real SQL Server in the container, in a database that belongs only to the tests. And where no SQL Server is running, these tests say so instead of being silently green.

What only the database knows

A test with a store in memory finds none of these bugs:

  • Unique constraints. Two requests check “is the time free?” at the same time, both see yes, both save. Only a unique index in SQL Server stops the second one (lesson 2.4.10).
  • Concurrent changes. A rowversion column and the answer 409 when someone else has changed the record in the meantime exist only in the database.
  • Queries that EF Core translates. A LINQ query that runs in memory may not be translatable into SQL and only fail with an exception against SQL Server, or it gets translated and does something different.
  • Comparison and sorting. In its usual setting, SQL Server compares texts without a difference between upper and lower case; a list in memory with == tells them apart. A search for “mara” finds “Mara Feld” in one case and not in the other.
  • Migrations. Whether the migrations build an empty database the way the model expects it is only shown by a run against an empty database.

For this you don’t need a new kind of test. It’s the same integration test with WebApplicationFactory, except that the real store with EF Core stays and points to a real database.