Available for PostgreSQL, Community and Team

Your database tests, in the pipeline that gates the merge.

For DevOps teams that gate merges and releases on evidence, not on a green that means nothing ran.

JUnit, Cobertura, LCOV and HTML from one run
Formats your CI panels and dashboards already read
A security leak or a false test exits non-zero
Runs on a throwaway database, never production

How to do it

Add one flag to the run you already do. The unit and integration commands both take it.

Install pgTAP and plpgsql_check on the CI database; connect with UNITAUTOGEN_DSN or the PG* variables.
Add --report to the default command, or to integration, and every CI report format lands in the --out folder:

unitautogen --schema public --report --out ci_out
# ci_out/  report.html  report.json  junit.xml  cobertura.xml  coverage.lcov

The same one line generates the tests, runs them, and writes the reports
The generated tests are standard pgTAP, so they also run later with psql or pg_prove alone

What lands in CI, and where it goes

Standard formats, so nothing needs a custom parser.

Test results go to junit.xml, which most CI test panels read directly.
Coverage dashboards read cobertura.xml or coverage.lcov, so Codecov, Coveralls and genhtml plot it and enforce your threshold on the pull request.
Human review uses report.html, kept as a build artifact, with one row per routine and the uncovered lines explained.
Machine steps read report.json, one entry per routine, for a custom badge or a policy check.

Gating the merge and the release

A build that proves nothing should not go green. These are the exit codes to wire to a required check.

A prerequisite is missing, so nothing was generated, exits 3
The security pass finds a data leak, with seccover --sec-gate, exits 4
A self-check failure or a would-be false test exits non-zero, treat it as a bug report
Coverage below your bar is enforced by the dashboard reading the Cobertura or LCOV file

A GitHub Action that runs on every pull request looks like this, and the same shape fits GitLab CI, Azure Pipelines or Jenkins.

jobs:
  db-tests:
    steps:
      - run: unitautogen --schema public --report --out ci_out
      - run: unitautogen seccover --schema public --sec-gate   # exits 4 on a leak
      - uses: actions/upload-artifact@v4                        # keep report.html
        with: { path: ci_out/report.html }
      - uses: codecov/codecov-action@v4                         # coverage.lcov -> the PR
        with: { files: ci_out/coverage.lcov }

The report a reviewer opens

One row per routine, its branch and statement coverage
Uncovered lines named, with why an input never reached them
The integration report adds one row per root, click it for the call map
The same generator, seed data and format for unit and integration

UnitAutogen coverage report kept as a CI build artifact

How it fits a pipeline

Developers run the unit tests as they work, free in the Community Edition
CI runs the same tests with --report on every push, one command
QA adds the integration run on the Team edition, same report format
Release pipelines add seccover --sec-gate so a leak blocks the ship
Everything runs on a throwaway copy of the database, never production
No scenarios or fixtures to write, so the suite never falls behind the code

Read the CI and CD docs Integration testing Editions

What platforms suggest

Running your database tests in CI is what the platform tells you to do.

Supabase shows a GitHub Action that runs your pgTAP tests on every pull request. UnitAutogen generates those tests and writes JUnit and coverage, so the same action gates the PR. Supabase, Automated testing using GitHub Actions →
Supabase recommends a required check that blocks a merge when the check fails. Point it at the UnitAutogen run, and a coverage drop or a security leak blocks the merge. Supabase, GitHub integration and required checks →