Test your application

Rent uses cargo nextest exclusively. PostgreSQL is the default integration target for Rent contributors:

just test

This starts isolated PostgreSQL on an available local port, runs driver, generated-client, native-type, and migration scenarios, then runs the regular workspace suite. The temporary database is removed afterward. Missing Docker or PostgreSQL fails the command; it never substitutes SQLite.

Run just PostgreSQL, or select a scenario by name:

just test-postgres
bash scripts/test-postgres.sh generated_client

Unit, compile, property, and in-memory SQLite tests remain available without Docker through focused nextest runs. For your own application, configure a dedicated test database and run its nextest suite; the just commands here operate from the Rent repository. Do not use a production database for integration tests.

The comprehensive repository gate includes the portability and extension matrices:

just check

You can also run those matrices separately:

just sql-matrix
just extension-matrix

The SQL matrix starts PostgreSQL, MySQL, and MariaDB with Docker Compose. The extension matrix separately tests stock PostgreSQL, Supabase PostgreSQL, TimescaleDB, and ParadeDB images. Each script tears down its containers when finished.

Supabase, TimescaleDB, and ParadeDB are PostgreSQL distributions used to verify extension behavior. They are not additional Rent database dialects. Rent's SQL dialects are PostgreSQL, MySQL/MariaDB, and SQLite.

Exercise a complete application

The social-network system test sends users, posts, comments, relations, eager loading, pagination, transactions, optimistic locking, access policies, and staged migrations through the generated client:

just system-social

Run concurrent reads, pages, optimistic updates, and transactions for a chosen duration:

RENT_SOAK_SECONDS=60 RENT_SOAK_WORKERS=16 just soak

The report includes total operations, expected optimistic conflicts, and p95 and p99 latency. The command fails on unexpected operation errors and on any configured performance threshold. The latency reservoir is bounded, so the observer itself does not grow with the duration of the run.

Coverage and mutation sensitivity

Merge ordinary and live PostgreSQL, MySQL, MariaDB, and SQLite execution into one coverage report:

just coverage-live

The gate requires at least 80% total line coverage and at least 60% in each critical runtime, driver, migration-plan, renderer, executor, and inspector module. Checked-in per-crate floors also prevent a well-covered package from hiding a regression in a different package.

Mutation tests prove that assertions reject deliberately altered behavior instead of only executing lines:

just mutants
./scripts/test-mutants-extensions.sh
just mutants-runtime
just mutants-live

Measure SDK overhead

Compare Rent with direct SQLx in the same process, pool, runtime, database, and result shape:

just benchmark-quick
just benchmark-live

The workloads cover point reads, policy-filtered reads, encrypted-field decoding, counts, offset and keyset pages, 16 concurrent reads, writes, upserts, transactions, optimistic updates, ordinary and high-fanout eager loading, a 1,000-row stream, and bulk inserts from 10 through 10,000 rows. SQLite always enforces per-workload median and sample-average p99 ceilings. Criterion's batch-average quantiles are not individual request-tail latencies. The live benchmark records the same comparison on every server database as trend data; on a stable, dedicated benchmark host, set RENT_BENCH_ENFORCE_SERVER_GATES=1 to enforce the checked-in server budgets too.

Exercise connection interruption and recovery separately:

just database-recovery

This restarts PostgreSQL, MySQL, and MariaDB while a Rent client is actively querying each server. The check fails unless the interruption is surfaced and the existing pool subsequently serves successful queries again.

Reverify every boundary

Before a local release candidate, run the single authoritative gate:

just reverify

It includes formatting, strict Clippy, nextest, docs and browser journeys, live coverage, migration comparison, application pressure and soak tests, fuzzing, Miri, sanitizers, dependency policy, benchmarks, mutation campaigns, compatibility checks, and private release artifacts.