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: