On Sat, Aug 8, 2015 at 9:47 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
