Re: Test code is worth the space
От | Greg Stark |
---|---|
Тема | Re: Test code is worth the space |
Дата | |
Msg-id | CAM-w4HMd8=H8BoDraUXE8jPcPfaTstyzKv=d85B=YKmLnGqXBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Test code is worth the space (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Test code is worth the space
Re: Test code is worth the space |
Список | pgsql-hackers |
On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch <noah@leadboat.com> wrote: > My own position is based on having maintained a pg_regress suite an order of > magnitude larger than that. I don't know why that outcome was so different. Comparing the size of test suites by these numbers is impossible because people put more or fewer tests in each schedule file. I would be more interested in the run-time as a metric but even that is fallible as I've seen individual tests that took 30min to run. And does your pg_regress test suite actually find many bugs or does it mainly detect when functionality has changed and require updating expected results to match? >> I suspect any effort to significantly improve Postgres test coverage is >> doomed until there's an alternative to pg_regress. > > There is the src/test/perl/TestLib.pm harness. Sadly I think the test suite is only half the battle. The coding style of Postgres predates modern test suite systems and makes it hard to test. Most functions require a specific environment set up that would be laborious and difficult to do in any sane way. Even something as self-contained as tuplesort would be difficult to test without the whole operator class and syscache mechanisms initialized and populated. And that's an easy case, imagine trying to test individual functions in the planner without doing a complete planner run on a query. -- greg
В списке pgsql-hackers по дате отправления: