Interesting enough concept. Please don't forget to test against a realistic data set as well. It does seem to me that the devs can easily make, fill, clean up their own db. And a central builder (eg Jenkins?) can do the same with, importantly using ALL tests. Then again using real data. > On Sep 15, 2014, at 8:08 AM, cowwoc <cowwoc@xxxxxxxxxxxxxxxx> 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 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 > > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
