Re: Contributing test cases to improve coverage
| От | J F |
|---|---|
| Тема | Re: Contributing test cases to improve coverage |
| Дата | |
| Msg-id | CAEFLKGjncwibWsaoTwfaOKJt2AkgT5V4PHQVZ8=bWWUxNZFpgQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Contributing test cases to improve coverage (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Contributing test cases to improve coverage
|
| Список | pgsql-hackers |
> I am quite confused about what is the point of this. You have not> found any actual bug, nor have you demonstrated that this test case> could discover a likely future bug that wouldn't be detected another> way. Moreover, it seems like the process would lead to some very> large number of equally marginal test cases. We aren't likely to> accept such a patch, because we are concerned about keeping down the> runtime of the test suite.>> regards, tom lane
The point of this project is to improve the coverage of PostgreSQL’s preexisting test suite. Writing a test suite to achieve close to 100% coverage is challenging, but I have proposed a workflow to automate this process.
I assert that no test case in the regression test suite currently covers the comparator in the expression rte->rtekind == RTE_SUBQUERY. I propose adding a new test case that addresses exactly this. In the future, if someone accidentally modifies the operator to become >=, it will trigger incorrect behavior when certain queries are executed. This test case will catch that issue.
I get that the test cases in /regress are likely reserved for actual bugs found and are designed to run quickly. Would it be a good idea to have a separate, more rigorous test suite that runs longer but provides better code coverage?
Regards,
Jon
В списке pgsql-hackers по дате отправления: