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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
