On Sat, Aug 8, 2015 at 9:47 AM, Noah Misch <noah@leadboat.com> wrote:
> We've too often criticized patches for carrying many lines/bytes of test case
> additions. Let's continue to demand debuggable, secure tests that fail only
> when something is wrong, but let's stop pushing for test minimalism. Such
> objections may improve the individual patch, but that doesn't make up for the
> chilling effect on test contributions. I remember clearly the first time I
> submitted thorough test coverage with a feature. Multiple committers attacked
> it in the name of brevity. PostgreSQL would be better off with 10x its
> current test bulk, even if the average line of test code were considerably
> less important than we expect today.
I strongly agree. I am fond of the example of external sorting, which
at present has exactly zero test coverage, even though in production
those code paths are exercised all the time.
I think that there needs to be a way of running an extended set of
regression tests. I could definitely respect the desire for minimalism
when it comes to adding tests to the regression tests proper if there
was an extended set of tests that could be run during development less
frequently. I thought about doing the extended set as a satellite
project, but that may not be workable.
--
Peter Geoghegan