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

Reply via email to