On Fri, Dec 5, 2014 at 04:10:12PM -0300, Alvaro Herrera wrote: > Well, ALTER TABLE is special: you can give several subcommands, and each > subcommand can be one of a rather long list of possible subcommands. > Testing every combination would mean a combinatorial explosion, which > would indeed be too large. But surely we want a small bunch of tests to > prove that having several subcommands works fine, and also at least one > test for every possible subcommand. > > > We have rejected simple regression test additions on the basis that > > the syntax works and is unlikely to break once tested once by the > > developer. > > This rationale doesn't sound so good to me. Something might work fine > the minute it is committed, but someone else might break it > inadvertently later; this has actually happened. Having no tests at all > for a feature isn't good. > > I know we have recently rejected patches that added tests only to > improve the coverage percent, for instance in CREATE DATABASE, because > the runtime of the tests got too large. Are there other examples of > rejected tests?
Yes, there are many cases we have added options or keywords but didn't add a regression test. > > > > and it could easily bloat the regression tests over time. > > > > > > We had 103 regression tests in 8.2 and we have 145 in 9.4. Does this > > > qualify as bloat? > > > > No, that seems fine. I am worried about having to have a test for every > > syntax change, which we currently don't do? Was that issue not clear in > > my first email? > > Well, if with "every syntax change" you mean "every feature addition", > then I think we should have at least one test for each, yes. It's not > like we add new syntax every day anyway. Well, my point is that this is a new behavior we have to do, at least to test the logical DDL behavior --- I suppose it could be remove after testing. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers