Integration tests verify that your code actually works with real external systems like SQL Server, Redis, or an external API.
The modern standard for integration testing. Instead of managing a 'shared' dev database, Testcontainers spins up a real SQL Server inside a Docker container just for your test run. It's clean, isolated, and ensures that your EF Core configurations (like unique constraints) are actually working in the real engine.
Use a library like **Respawn** to quickly reset the state of your test database between every test. This avoids 'pollution' where Test A fails because Test B left data in the table. Integration tests are slower than unit tests, but they provide the 'Sleep-at-night' assurance that the plumbing is correct.
Q: "Should I write integration tests for every repository method?"
Architect Answer: "Focus on the **Critical Paths**. Test complex queries, unique index violations, and multi-table transactions. Don't waste time testing simple 'Get By ID' calls unless there's custom logic involved. Your integration test suite should be the 'Heavy Artillery' that you roll out for the difficult parts of your infrastructure."