Re: Feature request: temporary schemas

On 09/15/2014 07:08 AM, cowwoc wrote:
> On 15/09/2014 9:39 AM, Adrian Klaver wrote:
>>>
>>> Not exactly. Each test is responsible for populating its own schema
>>> (creating tables, inserting data). The main purpose of using temporary
>>> schemas is to ensure that each test runs in isolation so that data from
>>> other tests cannot influence the outcome of the test. This ensures test
>>> execution/results are 100% reproducible.
>>
>> So the tests may or may not have anything to do with the existing test
>> database?
>
> Hi Adrian,
>
> I don't understand what you mean by "the existing test database". In my
> mind, tests have nothing in common with each other. They are meant to
> execute in complete isolation of each other.

From your second post:

" 1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
2. I need to create a new temporary schema per test, and run 4-10 of
tests per second. I'm guessing this wouldn't perform well using
"pg_ctl".
"

I took that to mean you want to create the temporary schemas over an
existing test database.

>
> It sounds to me like you thought I create a test database once
> (containing the tables, functions, triggers used by tests) and then
> running tests against that one at a time. In actuality, each test is
> expected to create its own tables, functions, triggers and execute
> concurrently and in complete isolation with other tests.
>
>
>>> One of the requirements is that if someone kills the process running the
>>> unit tests, it can't leave behind any dangling schemas. I expect all
>>> test data to get dropped automatically when the connection is closed
>>> unexpectedly, so DROP DATABASE won't do.
>>
>> I would think a DROP DATABASE IF EXISTS, CREATE DATABASE at the
>> beginning of the test would handle that.
>
> This would only clean up the next time tests are run. I'm looking for a
> cleanup at the end of the tests, not the beginning.
> As well, the fact that I have concurrent test execution means that I
> don't know how many databases/schemas there are to drop. I guess I could
> scan the database metadata for all test-related schemas but clearly this
> isn't as clean/fun as having temporary schemas in the first place.

I will admit to not being a testing expert, but from what I have done,
I know test suites have setup and teardown sections.

Would this not work?

My previous suggestion was a fall through for the case you mentioned
where a process is terminated outside the test.

>
> And lastly, remember that we want these tests to run as fast as
> possible. TEMPORARY/UNLOGGED tables are ideal from that point of view
> but I can't specify TEMPORARY/UNLOGGED because the unit tests and
> production code must share the same SQL script.

I can see that being possible. There will always be some difference
though as unit tests are not the same as rolling out production scripts.
The test code will need to include the actual test, unless I am missing
something obvious. Entirely possible:)

>
> Gili
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com