Re: dropping table in testcase alter_table.sql
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: dropping table in testcase alter_table.sql |
| Дата | |
| Msg-id | CAFjFpRfJnsd6X3jQoNrSfwYBXpVzzqNEAwoTHqmUOaHADzMvig@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: dropping table in testcase alter_table.sql (Peter Eisentraut <peter_e@gmx.net>) |
| Список | pgsql-hackers |
On Wed, Jul 13, 2011 at 2:53 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
If the tests are leaving behind the objects unintentionally, we can not be sure whether the state of the objects before upgrade/dump (or for that matter anything else) is intentional. If one needs to test upgrade and dump truly, the state of objects in the database, just before upgrading/dumping, needs to be arrived in a controlled manner. IOW, if a test wants to leave behind objects in certain state for some further testing, it should be "intentional". May be those objects should be annotated so (say, in the comments?). All the other objects be better cleaned up.
Said that, these particular two tables have very common names tab1 and tab2, which someone can pick up easily, thus linking two testcases unintentionally. So, at least we can make sure that if we use such common names for the objects, we clean them up at the end of test. If some object needs to be left behind we can give it a special name (say, the name includes the test case name, like alter_tab_tab1), so that there is lesser chance of interference with later tests. In case of #2 and #3 it also serves the purpose
1. Identifying the testcase which created/manipulated these objects last
2. We can trace the things that affected this object, before it came to a certain state.
This can be useful information in debugging problems.
On tis, 2011-07-12 at 08:51 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > It has occurred to me a few times that it could be useful to clarify the
> > approach here. If we could somehow have a separable cleanup step for
> > every test, and eliminate interdependencies between tests, we could more
> > easily support a number of uses cases such as creating a completely
> > populated regression test database for playing, or running tests in
> > random order or in differently parallelized scenarios.
>
> The limiting case of this is that each regression test script would be
> expected to start in an empty database and leave the DB empty on exit.
> I think that would make the tests less useful, not more, for several
> reasons:
>
> 1. They'd be slower, since every test would have to start by creating
> and populating some tables.
>
> 2. The final state of the regression database would no longer be useful
> as an environment for running ad-hoc manual tests.
>
> 3. The final state of the regression database would no longer be useful
> as a test case for pg_dump and pg_upgrade.
If the tests are leaving behind the objects unintentionally, we can not be sure whether the state of the objects before upgrade/dump (or for that matter anything else) is intentional. If one needs to test upgrade and dump truly, the state of objects in the database, just before upgrading/dumping, needs to be arrived in a controlled manner. IOW, if a test wants to leave behind objects in certain state for some further testing, it should be "intentional". May be those objects should be annotated so (say, in the comments?). All the other objects be better cleaned up.
Said that, these particular two tables have very common names tab1 and tab2, which someone can pick up easily, thus linking two testcases unintentionally. So, at least we can make sure that if we use such common names for the objects, we clean them up at the end of test. If some object needs to be left behind we can give it a special name (say, the name includes the test case name, like alter_tab_tab1), so that there is lesser chance of interference with later tests. In case of #2 and #3 it also serves the purpose
1. Identifying the testcase which created/manipulated these objects last
2. We can trace the things that affected this object, before it came to a certain state.
This can be useful information in debugging problems.
I think you misunderstood what I was saying. I wanted take out the
cleanup parts out of all test cases and make it a choice whether to run
them. Right now we have a lot of test cases that clean up after
themselves, which is useful in some cases (testing the cleaning, for one
thing), but not useful for 2. and 3.
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: