3
I built a small library to assert EF Core SQL query counts in integration tests (catch N+1 in 3 lines)
(programming.dev)
I kept running into the same issue when writing integration tests for ASP.NET Core APIs — there’s no clean way to assert how many SQL queries an endpoint executes.
Most of the time it ends up being:
- custom DbCommandInterceptor
- wiring it into WebApplicationFactory
- manually counting queries
So I wrapped that into a small library.
Example:
await using var guard = factory.TrackQueries<Program, AppDbContext>();
var client = guard.CreateClient();
await client.GetAsync("/api/orders");
guard.AssertCount(exact: 1);
That’s it — no manual interceptor or log parsing.
What it does:
- Counts SELECT/INSERT/UPDATE/DELETE queries triggered by HTTP requests
- Starts counting from CreateClient() (so startup/seeding queries are ignored)
- Works with any EF Core provider
- Designed for WebApplicationFactory-based integration tests
GitHub: https://github.com/KiwiDevelopment/KiwiQuery
NuGet: dotnet add package KiwiQuery.EFCore
MIT, very small codebase. Would love feedback — especially if you’re already solving this in a different way.
Is the MVC requirement a lib development dependency to cover MVC use cases, or can I only use it in MVC projects?
Looks like
WebApplicationFactoryis in the MVC namespace, so I assume this is only for MVC [integration] testing?Despite the name, WebApplicationFactory is not MVC-specific — it works with any ASP.NET Core app (Minimal APIs, Web API, MVC, Razor Pages). The "Mvc" in Microsoft.AspNetCore.Mvc.Testing is just historical baggage from before Minimal APIs existed. It's the standard integration testing host for the whole ASP.NET Core ecosystem. As for having it as a lib dependency: since KiwiQuery.EFCore is explicitly a testing library, pulling in a testing package is expected.