Re: Add additional information to src/test/ssl/README - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Add additional information to src/test/ssl/README |
Date | |
Msg-id | 984126.1635704915@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Add additional information to src/test/ssl/README (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Add additional information to src/test/ssl/README
|
List | pgsql-hackers |
I wrote: > Daniel Gustafsson <daniel@yesql.se> writes: >> Wouldn't it make more sense to start collecting troubleshooting advice in >> src/test/perl/README and instead refer to that in the boilerplate? I notice >> that we don't document for example PG_TEST_NOCLEAN anywhere (which admittedly >> is my fault), a trubleshooting section in that file would be a good fit. > Yeah, we could try to move all the repetitive stuff to there. I was a bit > allergic to the idea of having README files refer to webpages, because you > might be offline --- but referencing a different README doesn't have that > issue. Here's a quick stab at rearranging src/test/perl/README so that the initial section is all how-to-run-the-tests info, and advice about writing new tests starts after that. Your point about PG_TEST_NOCLEAN could be added into the initial section. I'd envision adding something like "See src/test/perl/README for more info about running these tests." to the boilerplate "Running the tests" section in src/test/ssl/README and its cohorts, but I didn't bother with that yet. regards, tom lane diff --git a/src/test/perl/README b/src/test/perl/README index 0e9a00ea05..f75b224175 100644 --- a/src/test/perl/README +++ b/src/test/perl/README @@ -12,22 +12,29 @@ $(prove_installcheck) targets in Makefile.global. By default every test in the t/ subdirectory is run. Individual test(s) can be run instead by passing something like PROVE_TESTS="t/001_testname.pl t/002_othertestname.pl" to make. -You should prefer to write tests using pg_regress in src/test/regress, or -isolation tester specs in src/test/isolation, if possible. If not, check to -see if your new tests make sense under an existing tree in src/test, like -src/test/ssl, or should be added to one of the suites for an existing utility. - -Note that all tests and test tools should have perltidy run on them before -patches are submitted, using perltidy --profile=src/tools/pgindent/perltidyrc - By default, to keep the noise low during runs, we do not set any flags via PROVE_FLAGS, but this can be done on the 'make' command line if desired, eg: make check-world PROVE_FLAGS='--verbose' +When a test fails, the terminal output from 'prove' is usually not sufficient +to diagnose the problem. Look into the log files that are left under +tmp_check/log/ to get more info. Files named 'regress_XXX' are log output +from the perl test scripts themselves, and should be examined first. +Other files are postmaster logs, and may be helpful as additional data. + + Writing tests ------------- +You should prefer to write tests using pg_regress in src/test/regress, or +isolation tester specs in src/test/isolation, if possible. If not, check to +see if your new tests make sense under an existing tree in src/test, like +src/test/ssl, or should be added to one of the suites for an existing utility. + +Note that all tests and test tools should have perltidy run on them before +patches are submitted, using perltidy --profile=src/tools/pgindent/perltidyrc + Tests are written using Perl's Test::More with some PostgreSQL-specific infrastructure from src/test/perl providing node management, support for invoking 'psql' to run queries and get results, etc. You should read the
pgsql-hackers by date: