Parameterize the conformance TCK by window; run it from JDBI - #9
Merged
Conversation
Make the velocity-testkit conformance TCK reusable by any backend regardless of window type, so every velocity-backend-* runs the SAME shared scenarios instead of bespoke tests (ADR 0004). Unblocks velocity-backend-redis (sliding) reusing the identical harness. - Parameterize the window-agnostic scenarios (Count/Sum/Distinct/PurgeStoreScenarios): the window(s) they exercise are now constructor parameters instead of a hardcoded sliding window. CountStoreScenarios takes a second distinct window for its apply- cardinality check. Assertions/values are otherwise unchanged (faithful refactor). - InMemoryVelocityBackendTck injects sliding windows (coverage unchanged). - velocity-backend-jdbi: JdbiConformanceTckTest now runs the SHARED Count/Sum/Distinct/ Purge scenarios with TUMBLING windows — including the shared concurrentApplyIsAtomic (acceptance #1) against real Postgres — plus Tumbling/Seed/Capability. Deleted the bespoke JdbiAggregationTest and JdbiConcurrencyTest (now superseded by the shared scenarios). - Close the apply-side gap the deletion exposed: added two SHARED scenarios to CapabilityConformanceScenarios — apply to an unsupported window -> distinguishable FAILED (never a silent APPLIED; ADR 0009), and a mixed supported+unsupported apply fails only the unsupported window (FR-34). Both run on InMemory and real Postgres. velocity-testkit 50 tests, velocity-backend-jdbi 29 tests (real Postgres, 0 skipped), whole project green (gate 80/70). Reviewed by the change-validator agent: VERDICT APPROVE (no scenario assertion weakened; shared scenarios genuinely running unskipped). The apply-side scenarios were added after its review to close the one gap it flagged. Follow-up (minor): the JDBI DataSource-constructor is no longer directly tested (the harness uses the Jdbi constructor) — a trivial delegating ctor; add a small test later. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make the
velocity-testkitconformance TCK reusable by any backend regardless of window type,so every
velocity-backend-*runs the same shared scenarios rather than bespoke tests (ADR 0004).This is the follow-up flagged in the JDBI PR — and it unblocks
velocity-backend-redis(sliding),which now reuses the identical harness with sliding windows.
What changed
Count/Sum/Distinct/PurgeStoreScenarios): thewindow(s) they exercise are now constructor parameters instead of a hardcoded sliding window.
CountStoreScenariosalso takes a second, distinct window for its apply-cardinality check. Theassertions, expected values, and logic are otherwise byte-for-byte unchanged — a faithful refactor
(the change-validator confirmed no assertion was weakened).
InMemoryVelocityBackendTckinjects sliding windows — its coverage is unchanged.velocity-backend-jdbinow runs the sharedCount/Sum/Distinct/Purgescenarios withtumbling windows — including the shared
concurrentApplyIsAtomic(acceptance Bump actions/setup-java from 5.5.0 to 5.6.0 in the gh-actions group #1) against realPostgres — alongside
Tumbling/Seed/Capability. Deleted the bespokeJdbiAggregationTestandJdbiConcurrencyTest, now superseded.shared scenarios to
CapabilityConformanceScenarios— applying to an unsupported window yieldsa distinguishable
FAILED(never a silentAPPLIED; ADR 0009), and a mixed supported +unsupported apply fails only the unsupported window (FR-34, per-feature partial outcome). Both run
on the in-memory backend and real Postgres, so every backend now verifies apply-side behavior too.
Result
velocity-testkit: 50 tests, 0 skipped.velocity-backend-jdbi: 29 tests against realPostgres, 0 skipped.
./gradlew buildgreen across all modules (gate 80/70).Review
change-validatoragent: VERDICT APPROVE — verified the parameterization is faithful (assertionsintact), both modules green, and the shared scenarios genuinely run unskipped against real Postgres.
The two apply-side scenarios were added after its review to close the single gap it identified.
Follow-up (minor)
The JDBI
DataSourceconstructor is no longer directly exercised (the test harness builds the backendvia the
Jdbiconstructor) — a trivial delegating ctor; worth a one-line test later.🤖 Generated with Claude Code