PG_PROVE(1p)
β¨ pg_prove(1p) β User Contributed Perl Documentation β¨
Okay bestie, gather round, because this is the manual for pg_prove, and it's literally the tool that runs your pgTAP tests in a PostgreSQL database. No cap. π
πΈ Name πΈ
pg_prove β a command-line tool for running and harnessing pgTAP tests
π Usage π
pg_prove tests/
pg_prove --dbname template1 test*.sql
pg_prove -d testdb --runtests
π Description π
pg_prove is a command-line application to run one or more pgTAP tests in a PostgreSQL database. The pgTAP homepage is at https://pgtap.org/. The output of the tests is harvested and processed by TAP::Harness in order to summarize the results of the test.
pg_prove relies on psql to run the tests. The psql docs live at https://www.postgresql.org/docs/current/app-psql.html. Because of that, it supports all of the environment variables at https://www.postgresql.org/docs/current/libpq-envars.html, as well as the password file at https://www.postgresql.org/docs/current/libpq-pgpass.html and the service file at https://www.postgresql.org/docs/current/libpq-pgservice.html read by psql.
Tests can be written and run in one of two ways, as SQL scripts or as xUnit-style database functions.
π§ͺ Test Scripts π§ͺ
pgTAP test scripts should consist of a series of SQL statements that output TAP. Here's a simple example that assumes that the pgTAP functions have been installed in the database:
-- Start transaction and plan the tests.
BEGIN;
SELECT plan(1);
-- Run the tests.
SELECT pass( 'My test passed, w00t!' );
-- Finish the tests and clean up.
SELECT * FROM finish();
ROLLBACK;
Now run the tests by passing the list of SQL script names or the name of a test directory to pg_prove. Here's what it looks like when the pgTAP tests are run with pg_prove:
% pg_prove -U postgres tests/
tests/coltap.....ok
tests/hastap.....ok
tests/moretap....ok
tests/pg73.......ok
tests/pktap......ok
All tests successful.
Files=5, Tests=216, 1 wallclock secs ( 0.06 usr 0.02 sys + 0.08 cusr 0.07 csys = 0.23 CPU)
Result: PASS
π¦ xUnit Test Functions π¦
pgTAP test functions should return a set of text, and then simply return the values returned by pgTAP functions, like so:
CREATE OR REPLACE FUNCTION setup_insert(
) RETURNS SETOF TEXT AS $$
RETURN NEXT is( MAX(nick), NULL, 'Should have no users') FROM users;
INSERT INTO users (nick) VALUES ('theory');
$$ LANGUAGE plpgsql;
Create OR REPLACE FUNCTION test_user(
) RETURNS SETOF TEXT AS $$
SELECT is( nick, 'theory', 'Should have nick') FROM users;
END;
$$ LANGUAGE sql;
Once you have these functions defined in your database, you can run them with pg_prove by using the --runtests option.
% pg_prove --dbname mydb --runtests
runtests()....ok
All tests successful.
Files=1, Tests=32, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.00 csys = 0.04 CPU)
Result: PASS
Be sure to pass the --schema option if your test functions are all in one schema, and the --match option if they have names that don't start with test. For example, if you have all of your test functions in the test schema and ending with test, run the tests like so:
pg_prove --dbname mydb --schema test --match 'test$'
β¨ Options β¨
Okay so here's the whole menu of flags. Every single one, no skips. π
-b,--psql-bin PSQLβ Location of the psql client.-d,--dbname DBNAMEβ Database to which to connect.-U,--username USERNAMEβ User with which to connect.-h,--host HOSTβ Host to which to connect.-p,--port PORTβ Port to which to connect.-P,--pset OPTION=VALUEβ Set psql key/value printing option.-S,--set VAR=VALUEβ Set variables for psql session.-R,--runtestsβ Run xUnit test using runtests().-s,--schema SCHEMAβ Schema in which to find xUnit tests.-x,--match REGEXβ Regular expression to find xUnit tests.--extβ Set the extension for tests (default .pg)-r,--recurseβ Recursively descend into directories.--ignore-exitβ Ignore exit status from test scripts.--trapβ Trap Ctrl-C and print summary on interrupt.--harnessβ Define test harness to use.-j,--jobs Nβ Run N test jobs in parallel (try 9.)--rc RCFILEβ Process options from rcfile--norcβ Don't process default .proverc--state OPTION=VALUEβ Set persistent state options.-v,--verboseβ Print all test lines.-f,--failuresβ Show failed tests.-o,--commentsβ Show comments and diagnostics.--directivesβ Only show results with TODO or SKIP directives.-q,--quietβ Suppress some test output while running tests.-Q,--QUIETβ Only print summary results.--parseβ Show full list of TAP parse errors, if any.--normalizeβ Normalize TAP output in verbose output-D,--dryβ Dry run. Show test that would have run.--mergeβ Merge test scripts' STDERR and STDOUT.-t,--timerβ Print elapsed time after each test.-c,--colorβ Colored test output (default).--nocolorβ Do not color test output.--shuffleβ Run the tests in random order.--reverseβ Run the tests in reverse order.-a,--archive FILENAMEβ Store the resulting TAP in an archive file.--formatterβ Result formatter to use.--countβ Show X/Y test count when not verbose (default)--nocountβ Disable the X/Y test count.-H,--helpβ Print a usage statement and exit.-?β Print a usage statement and exit.-m,--manβ Print the complete documentation and exit.-V,--versionβ Print the version number and exit.
π Options Details π
ποΈ Database Options ποΈ
-b, --psql-bin
pg_prove --psql-bin /usr/local/pgsql/bin/psql
pg_prove -b /usr/local/bin/psql
Path to the psql program, which will be used to actually run the tests. Defaults to psql, which should work well, when it is in your path. π
-d, --dbname
pg_prove --dbname try
pg_prove -d postgres
The name of database to which to connect. Defaults to the value of the $PGDATABASE environment variable or to the system username.
-U, --username
pg_prove --username foo
pg_prove -U postgres
PostgreSQL user name to connect as. Defaults to the value of the $PGUSER environment variable or to the operating system name of the user running the application.
-h, --host
pg_prove --host pg.example.com
pg_prove -h dev.local
Specifies the host name of the machine on which the server is running. If the value begins with a slash, it is used as the directory for the Unix-domain socket. Defaults to the value of the $PGHOST environment variable or localhost.
-p, --port
pg_prove --port 1234
pg_prove -p 666
Specifies the TCP port or the local Unix-domain socket file extension on which the server is listening for connections. Defaults to the value of the $PGPORT environment variable or, if not set, to the port specified at compile time, usually 5432.
-P, --pset
pg_prove --pset tuples_only=0
pg_prove -P null=[NULL]
Specifies printing options in the style of \pset in the psql program. See https://www.postgresql.org/docs/current/static/app-psql.html for details on the supported options.
-S, --set
pg_prove --set MY_CONTRACT=321
pg_prove -S TEST_SEARCH_PATH=test,public
Sets local variables for psql in the style of \set in the psql program. See https://www.postgresql.org/docs/current/static/app-psql.html for details on the supported options.
--runtests
pg_prove --runtests
pg_prove -r
Don't run any test scripts, but just use the runtests() pgTAP function to run xUnit tests. This ends up looking like a single test script has been run, when in fact no test scripts have been run. Instead, pg_prove tells psql to run something like:
psql --command 'SELECT * FROM runtests()'
You should use this option when you've written your tests in xUnit style, where they're all defined in test functions already loaded in the database.
-s, --schema
pg_prove --schema test
pg_prove -s mytest
Used with --runtests, and, in fact, implicitly forces --runtests to be true. This option can be used to specify the name of a schema in which to find xUnit functions to run. Basically, it tells psql to run something like:
psql --command "SELECT * FROM runtests('test'::name)"
-x, --match
pg_prove --match 'test$'
pg_prove -x _test_
Used with --runtests, and, in fact, implicitly forces --runtests to be true. This option can be used to specify a POSIX regular expression that will be used to search for xUnit functions to run. Basically, it tells psql to run something like:
psql --command "SELECT * FROM runtests('_test_'::text)"
This will run any visible functions with the string _test_ in their names. This can be especially useful if you just want to run a single test in a given schema. For example, this:
pg_prove --schema testing --match '^test_widgets$'
Will have psql execute the runtests() function like so:
SELECT * FROM runtests('testing'::name, '^test_widgets$'::text);
π Behavioral Options π
--ext
pg_prove --ext .sql tests/
Set the extension for test files (default .pg). May be specified multiple times if you have test scripts with multiple extensions, though all must be pgTAP tests:
pg_prove --ext .sql --ext .pg --ext .pgt
If you want to mix pgTAP tests with other TAP-emitting tests, like Perl tests, use prove instead, where --ext identifies any test file, and --pgtap-option suffix= lets you specify one or more extensions for pgTAP tests.
prove --source Perl \
--ext .t --ext .pg \
--source pgTAP --pgtap-option suffix=.pg
-r, --recurse
pg_prove --recurse tests/
pg_prove --recurse sql/
Recursively descend into directories when searching for tests. Be sure to specify --ext if your tests do not end in .pg. Not relevant with --runtests.
--ignore-exit
pg_prove --ignore-exit
--ignore-exitβ ignore the exit status coming back from test scripts. Normally if a script triggers a database exception,psqlexits with an error code and, even if literally every test passed, the whole thing gets counted as a failure. Use--ignore-exitto ignore those situations β (at your own peril, bestie π)--trapβ trapCtrl-Cand print a summary on interrupt.
pg_prove --trap
--harnessβ specify a subclass ofTAP::Harnessto use for the test harness. Defaults toTAP::Harnessβ unless--archiveis specified, in which case it usesTAP::Harness::Archive.
pg_prove --harness TAP::Harness::Color
-j,-jobsβ run N test jobs in parallel (try 9.) parallelism era β¨--rcβ process options from the specified configuration file.
pg_prove --rc pg_prove.rc
If --rc isn't specified and ./.proverc or ~/.proverc exist, they get read and the options they contain get processed before the command line options. Options in config files are written exactly the same way as command line options:
# .proverc
--state=hot,fast,save
-j9
Under Windows and VMS the option file is named _proverc rather than .proverc, and it's only looked for in the current directory.
Because of how options are loaded you cannot use .proverc for pg_prove-specific options β only prove options. That said, pg_prove does support all of the usual libpq environment variables (the docs live at https://www.postgresql.org/docs/current/static/libpq-envars.html). π
--norcβ do not process./.provercor~/.proverc.--stateβ this one lets you askpg_proveto remember the state of previous test runs and then select and/or order the tests based on that saved state. π
The --state switch needs an argument, and that argument has to be a comma-separated list of one or more of the options below:
lastβ run the same tests as the last time the state was saved. This makes it possible, for example, to recreate the ordering of a shuffled test.
# Run all tests in random order
pg_prove --state save --shuffle
# Run them again in the same order
pg_prove --state last
failedβ run only the tests that failed on the last run.
# Run all tests
pg_prove --state save
# Run failures
pg_prove --state failed
If you also specify the save option, newly passing tests will be excluded from subsequent runs.
# Repeat until no more failures
pg_prove --state failed,save
passedβ run only the tests that passed last time. Super useful for making sure no new problems have snuck in. π¦allβ run all tests in normal order. You can specify multiple options, so to run all tests with last time's failures first:
pg_prove --state failed,all,save
hotβ run the tests that most recently failed first. The last failure time of each test is stored, andhotmakes tests run in most-recent-failure order.
pg_prove --state hot,save
Tests that have never failed won't be selected. To run all tests with the most recently failed first, use:
pg_prove --state hot,all,save
This same combination of options may also be specified like this:
pg_prove --state adrian
todoβ run any tests with todos.slowβ run the tests in slowest-to-fastest order. This is chef's kiss alongside the-jparallel testing switch, because it makes sure your slowest tests start running first.
pg_prove --state slow -j9
fastβ run the tests in fastest-to-slowest order.newβ run the tests in newest-to-oldest order, based on the modification times of the test scripts.oldβ run the tests in oldest-to-newest order.freshβ run those test scripts that have been modified since the last test run.saveβ save the state on exit. The state is stored in a file called.pg_prove(_pg_proveon Windows and VMS) in the current directory.
The --state switch may be used more than once. π
pg_prove --state hot --state all,save
β¨ Display Options β¨
-v,--verboseβ display standard output of test scripts while they're running. You can also trigger this behavior by setting the$TEST_VERBOSEenvironment variable to a true value.
pg_prove --verbose
pg_prove -v
-f,--failuresβ show failed tests.
pg_prove --failures
pg_prove -f
-o,--commentsβ show comments, like diagnostics output bydiag(). It's enabled by default, so use--no-commentsto disable it.--directivesβ only show results with TODO or SKIP directives.
pg_prove --directives
-q,--quietβ suppress some test output while running tests.
pg_prove --quiet
pg_prove -q
-Q,--QUIETβ only print summary results. (yes, uppercase bestie, they're different π)
pg_prove --QUIET
pg_prove -Q
--parseβ enables the display of any TAP parsing errors as tests run. Handy for debugging new TAP emitters.
pg_prove --parse
--normalizeβ normalize TAP output in verbose output. Errors in the harnessed TAP that get corrected by the parser will be corrected.
pg_prove --normalize
--dry,-Dβ dry run. Just outputs a list of the tests that would have been run.
pg_prove --dry tests/
pg_prove -D
--mergeβ merge test scripts'STDERRwith theirSTDOUT. Not really relevant to pgTAP tests, which only print toSTDERRwhen an exception is thrown.-t,--timerβ print elapsed time after each test file. β±οΈ
pg_prove --timer
pg_prove -t
-c,--colorβ display test results in color. Colored test output is the default, but if the output isn't going to a terminal, color gets disabled.
Requires Term::ANSIColor on Unix-like platforms and Win32::Console on Windows. If the necessary module isn't installed, colored output won't be available. π
pg_prove --color
pg_prove -c
--nocolorβ do not display test results in color.--shuffleβ test scripts are normally run in alphabetical order. Use--reverseto run them in in random order. Not relevant when used with--runtests.
pg_prove --shuffle tests/
okay so the manpage really does say --reverse in that sentence and I'm just relaying it verbatim, don't come for me π
--reverseβ test scripts are normally run in alphabetical order. Use--reverseto run them in reverse order. Not relevant when used with--runtests.
pg_prove --reverse tests/
-a,--archiveβ send the TAP output to a TAP archive file as well as to the normal output destination. The archive formats supported are.tarand.tar.gz. π
pg_prove --archive tap.tar.gz
pg_prove -a test_output.tar
-f,--formatterβ the name of the class to use to format output. The default isTAP::Formatter::Console, orTAP::Formatter::Fileif the output isn't a TTY.
pg_prove --formatter TAP::Formatter::File
pg_prove -f TAP::Formatter::Console
--countβ show the X/Y test count as tests run when not verbose (this is the default).
pg_prove --count
--nocountβ disable the display of the X/Y test count as tests run.
pg_prove --nocount
πΈ Metadata Options πΈ
-H,-?,--helpβ outputs a brief description of the options supported bypg_proveand exits.
pg_prove --help
pg_prove -H
-m,--manβ outputs this documentation and exits. (hi, you're reading it π«Ά)
pg_prove --man
pg_prove -m
-V,--versionβ outputs the program name and version and exits.
pg_prove --version
pg_prove -V
π Author π
David E. Wheeler <dwheeler@cpan.org>
π Copyright π
Copyright (c) 2008-2025 David E. Wheeler. Some Rights Reserved.
and that's the whole page, bestie β¨ this one's from perl v5.40.1, dated 2025-04-09, and it ate, no cap. go write some tests π
π¦ where this page comes from
- debian trixie: libtap-parser-sourcehandler-pgtap-perl 3.37-1 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu resolute: libtap-parser-sourcehandler-pgtap-perl 3.37-1 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu stonking: libtap-parser-sourcehandler-pgtap-perl 3.37-1 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms