Follow-up: detecting EF Core query regressions in tests
A few days ago I asked how people detect N+1 / query regressions in EF Core integration tests:
https://www.reddit.com/r/dotnet/comments/1sjrm6s/how_are_you_detecting_n1_query_regressions_in_ef/
Got a lot of useful replies — some rely on profiling, some don't check it at all, and a few mentioned interceptors.
I ended up going deeper into the interceptor approach and built a small wrapper around it.
The goal was simple: make query regressions fail tests automatically instead of trying to notice them manually.
Something like:
await using var guard = QueryGuard.Start();
var client = guard.CreateClient();
await client.GetAsync("/api/orders");
guard.AssertCount(atMost: 3);
If query count unexpectedly increases, the test fails.
I actually had a case where an endpoint went from 2 queries to 15 after a refactor — tests still passed, and I didn’t notice until later. This approach would have caught it immediately.
It turned out to be pretty useful for catching things like N+1 or accidental lazy loading during refactors.
Curious if this approach makes sense, or if there are better ways to handle this.
I extracted it into a small open-source tool (v1.0):