Contents
PostgreSQL Regression Tests for ParadeDB
This directory contains the pg regress tests for ParadeDB’s pg_search extension. These run with cargo pgrx regress and do not need the extension to be manually installed: it is handled automatically.
For a complete overview of ParadeDB’s testing infrastructure (including unit tests, integration tests, and client property tests), please see the Testing section in CONTRIBUTING.md.
Directory Structure
sql/: Contains SQL script files that are executed during testingexpected/: Contains expected output files for each testresults/(ignored under git): Stores actual output files generated during test runscommon/: Contains common setup and cleanup scripts used by multiple tests
Adding New Tests
Step 1: Create the SQL Test
- Name the file after the feature, behavior, or issue it covers, following nearby tests.
- If the test belongs to a group with shared setup, include the corresponding script from
common/, for example:
\i common/PREFIX_setup.sql
- Add a short comment describing the behavior under test:
-- Tests my new feature
- Make output deterministic, including an
ORDER BYwherever row order matters. - If the test uses shared setup, include the matching cleanup script at the end:
\i common/PREFIX_cleanup.sql
Step 2: Generate the Expected Output
Bootstrap the test and promote its output to expected/:
cd pg_search
cargo pgrx regress --add PREFIX_your_test
Pass a PostgreSQL version before --add to use a version other than the default, for example cargo pgrx regress pg17 --add PREFIX_your_test.
Step 3: Verify the Expected Output
- Check the generated output file in
expected/PREFIX_your_test.out - Verify that results and errors demonstrate the intended behavior.
- Verify that any
EXPLAINplans use stable options and the expected execution path.
Running Tests
Run All Tests
cd pg_search
cargo pgrx regress
Run Specific Tests
cd pg_search
cargo pgrx regress pg18 PREFIX_your_test
Use --auto only when you intentionally want to replace the expected output of a failing test with its current output.
Common Pitfalls
- Non-deterministic Results: Use fixed dates and ORDER BY clauses to ensure consistent results
- Missing Data: Verify that all test queries return at least one row of data
- Timing Variations: Use
COSTS OFF, TIMING OFFin EXPLAIN to avoid timing-dependent output
Contributing New Tests
When contributing new tests:
- Follow the naming convention of existing tests
- Use the appropriate common setup/cleanup scripts
- Check that your test produces deterministic results
- Include metadata comments at the top of the file explaining what’s being tested