Stream: dev

Topic: Test: DB Query Assertions & N+1 Detection (QuickPerf)

view this post on Zulip Tony Nguyen (Sep 24 2026 at 19:21):

Hi all! :wave:

Following up on the open note in the Developer Performance Guide ("Count Database Queries per API Test: Is it possible?") and the recent great work on DB query scaling in #12740 and #12729:

I put together a working POC integrating QuickPerf (JUnit 5) into our test suite on my fork:
:link: POC PR: https://github.com/tuannx/dataverse/pull/3

QuickPerf vs. Direct datasource-proxy (Trade-offs)

Since we already have datasource-proxy 1.11.0 in develop, here is a quick look at how the two compare:

Aspect Direct datasource-proxy (Current) QuickPerf (POC)
Ergonomics Manual clear(), lambda wrapping, manual asserts Declarative annotations (e.g. @ExpectMaxSelect(25))
N+1 Detection Runs against 2 dataset sizes (e.g. 50 vs 100 files) to check slope Catches N+1 on a single dataset via prepared statement parameters
Failure Diagnostics Bare assert (expected < 5, was 809); requires manual SQL log inspection Dumps the exact repeated SQL statements & parameter diff in test output
Safety Guards None out of the box Built-in @ExpectUpdate(0), wildcard scan checks, batching checks
Dependency & Maintenance In-tree, zero new dependencies Adds test-scoped lib. Note: Upstream QuickPerf master has merged datasource-proxy 1.11.0, but a new Maven Central release is still pending (latest published is 1.1.0).

Open Question for the Team:

Would the core team prefer:

  1. Adopting QuickPerf (100% test-scoped) once the release is cut to get declarative annotations and automatic N+1 diagnostics?
  2. Or keeping direct datasource-proxy 1.11.0 and writing a lightweight internal test utility inspired by QuickPerf's assertion pattern?

Would love to hear thoughts from @Philip Durbin 🚀 , @Oliver Bertuch and @Eryk Kulikowski !

view this post on Zulip Philip Durbin 🚀 (Sep 24 2026 at 19:27):

@Oliver Bertuch you were interested QuickPerf. Please see above. What do you think?

view this post on Zulip Oliver Bertuch (Sep 24 2026 at 22:14):

I'm happy if @Tony Nguyen wants to have a go at this! It would be interesting to see and I appreciate someone continuing the work I started (also very happy to see @Eryk Kulikowski just used the framework :smiley_cat: ).

Some (helpful?) comments:

  1. I already added an annotation @JpaPerformanceTest. Adding @QuickPerfTest to it is a low hanging fruit, auto-enabling all existing tests to use QuickPerf. (You probably saw how it also triggers wiring up the datasource, Testcontainers, etc)
  2. As the general performance guide is rather superficial, I created https://guides.dataverse.org/en/6.12/developers/testing/performance.html when writing the test infrastructure back in the day. That would need to be updated that we use Quickperf, how to use it and so on.
  3. W.r.t. "can we cound SQL queries in API tests": no, at least not with QuickPerf. It runs as part of the JUnit test and for API tests, we reach out over the network to a _different_ JVM, which accesses the DB. QuickPerf has no chance of intercepting that. To get a hold of that data we'd need a Java agent (JProfiler and other do it that way) or use a more complex OpenTelemetry setup. But using QuickPerf would already be a nice addition for our integration performance tests!
  4. Let me point you to an important aspect of it all: we are neither using Hibernate nor Spring Data. There is no integration with EclipseLink, so QuickPerf cannot give us helpful hints to optimize queries. But it can of course still analyze the JDBC traffic for patterns and fail tests, but we have to think more about the right limits for a test and how to optimize.

Last updated: Nov 02 2026 at 07:01 UTC