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.
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.
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.
Gili