Re: Add more regression tests for dbcommands

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add more regression tests for dbcommands
Дата
Msg-id 8538.1372263438@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add more regression tests for dbcommands  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Add more regression tests for dbcommands  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Add more regression tests for dbcommands  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> I am generally a bit unsure whether the regression tests you propose
> aren't a bit too verbose. Does any of the committers have an opinion
> about this?

> My feeling is that they are ok if they aren't slowing down things much.

Yeah, I'm concerned about speed too.  If the regression tests take a
long time it makes it harder for developers to run them.  (I like to
point at mysql's regression tests, which take well over an hour even on
fast machines.  If lots of tests are so helpful, why is their bug rate
no better than ours?)

I was intending to suggest that much of what Robins has submitted
doesn't belong in the core regression tests, but could usefully be put
into an optional set of "big" regression tests.  We already have a
"numeric_big" test in that spirit.  What seems to be lacking is an
organizational principle for this (should the "big" tests live with the
regular ones, or in a separate directory?) and a convenient "make"
target for running the big ones.  Once we had a setup like that, we
could get some or all of the buildfarm machines to run the "big" tests,
but we wouldn't be penalizing development work.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Kudos for Reviewers -- straw poll
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: fixing pg_ctl with relative paths