Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)
От | Noah Misch |
---|---|
Тема | Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump) |
Дата | |
Msg-id | 20160523032218.GD4184@gust обсуждение исходный текст |
Ответ на | Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)
|
Список | pgsql-hackers |
On Sun, May 08, 2016 at 12:29:27PM -0400, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: > > My suggestion is that, from this point forward, we add new tests to > > 9.6 only if they are closely related to a bug that is getting fixed or > > a feature that is new in 9.6. I think that's a reasonable compromise, > > but what do others think? +1. This is a natural extension of the well-established default that we (back-)patch tests for a bug into all releases getting a fix for the bug. > I'm willing to accept that compromise, but I'm not thrilled with it due > to what it will mean for the process I'm currently going through. The > approach I've been using has been to add tests to gain more code > coverage of the code in pg_dump. That has turned up multiple > pre-existing bugs in pg_dump but the vast majority of the tests come > back clean. This compromise would mean that I'd continue to work > through the code coverage tests, but would have to segregate out and > commit only those tests which actually reveal bugs, once those bugs have > been fixed (as to avoid turning the buildfarm red). The rest of the > tests would still get written, but since they currently don't reveal > bugs, they would be shelved until development is opened for 9.7. Some or even most of the other tests would qualify under "closely related to ... a feature that is new in 9.6". Your 9.6 pg_dump changes affected object selection and catalog extraction for most object types, so I think validating those paths is in scope under Robert's suggestion. Testing "pg_dump --encoding" or "pg_dump --jobs" probably wouldn't fall in scope, because those features operate at arm's length from the 9.6 pg_dump changes. Expanding, for example, tests of postgres_fdw query deparse would certainly fall out of scope. That would have no apparent chance of catching a regression caused by the 9.6 pg_dump changes.
В списке pgsql-hackers по дате отправления: