Re: Test code is worth the space

On 10 August 2015 at 13:55, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs <simon(at)2ndquadrant(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services