On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch <noah@leadboat.com> wrote:
> My own position is based on having maintained a pg_regress suite an order of
> magnitude larger than that. I don't know why that outcome was so different.
Comparing the size of test suites by these numbers is impossible
because people put more or fewer tests in each schedule file. I would
be more interested in the run-time as a metric but even that is
fallible as I've seen individual tests that took 30min to run.
And does your pg_regress test suite actually find many bugs or does it
mainly detect when functionality has changed and require updating
expected results to match?
>> I suspect any effort to significantly improve Postgres test coverage is
>> doomed until there's an alternative to pg_regress.
>
> There is the src/test/perl/TestLib.pm harness.
Sadly I think the test suite is only half the battle. The coding style
of Postgres predates modern test suite systems and makes it hard to
test. Most functions require a specific environment set up that would
be laborious and difficult to do in any sane way. Even something as
self-contained as tuplesort would be difficult to test without the
whole operator class and syscache mechanisms initialized and
populated. And that's an easy case, imagine trying to test individual
functions in the planner without doing a complete planner run on a
query.
--
greg
