Re: Test code is worth the space - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Test code is worth the space
Date
Msg-id CANP8+jJBhccy4mvnYvTQGeXMbw0eRqX7wDRVvkFDKN-i-5E6zA@mail.gmail.com
Whole thread Raw
In response to Re: Test code is worth the space  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 10 August 2015 at 13:55, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On another review I suggested we add a function to core to allow it to be
> used in regression tests. A long debate ensued, deciding that we must be
> consistent and put diagnostic functions in contrib. My understanding is that
> we are not allowed to write regression tests that use contrib modules, yet
> the consistent place to put diagnostic functions is contrib - therefore, we
> are never allowed to write tests utilizing diagnostic functions. We are
> allowed to put modules for testing in another directory, but these are not
> distributed to users so cannot be used for production diagnosis. Systemic
> fail, advice needed.

There are actually two ways to do this.

One model is the dummy_seclabel module.  The build system arranges for
that to be available when running the core regression tests, so they
can use it.  And the dummy_seclabel test does.  There are actually a
couple of other loadable modules that are used by the core regression
tests in this kind of way (refint and autoinc, from contrib/spi).

The other model is what I'll call the test_decoding model.  Since the
core code can't be tested without a module, we have a module.  But
then the tests are in the module's directory
(contrib/test_decoding/{sql,expected}) not the core regression tests.

In general, I have a mild preference for the second model.  It seems
more scalable, and keeps the core tests quick to run, which is
appropriate for more obscure tests that are unlikely to break very
often.  But the first model can also be done, as show by the fact that
we have in fact done it several times.

Neither of those uses a diagnostic function that also has value in production environments - for logical decoding we added something to core specifically to allow this pg_recvlogical.

Anyway, resolving this isn't important anymore because I wish to pursue a different mechanism for freezing, but its possible I hit the same issue.
 
--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Andrew Dunstan
Date:
Subject: Re: tap tests remove working directories