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 <cow...@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 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
