Interesting enough concept. Please don't forget to test against a realistic data set as well. It does seem to me that
thedevs can easily make, fill, clean up their own db. And a central builder (eg Jenkins?) can do the same with,
importantlyusing ALL tests.
Then again using real data.
> On Sep 15, 2014, at 8:08 AM, cowwoc <cowwoc@bbs.darktech.org> 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.
>
> 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
todrop. I guess I could scan the database metadata for all test-related schemas but clearly this isn't as clean/fun as
havingtemporary 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
thatpoint of view but I can't specify TEMPORARY/UNLOGGED because the unit tests and production code must share the same
SQLscript.
>
> Gili
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general