From: Scott Marlowe <scott.marlowe@gmail.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Nikolas Everett <nik9000@gmail.com>
Cc: jd@commandprompt.com <jd@commandprompt.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Michael Clemmons <glassresistor@gmail.com>
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Date: Fri, 11 Dec 2009 15:19:05 -0700
Message-ID: <dcc563d10912111419y5074fab3w7f620a28a141012@mail.gmail.com> (raw)
In-Reply-To: <C74803DD.1B1BF%scott@richrelevance.com>
References: <dcc563d10912111357k538816baybbfdbe3b846f7aa3@mail.gmail.com>
<C74803DD.1B1BF%scott@richrelevance.com>
On Fri, Dec 11, 2009 at 3:12 PM, Scott Carey <scott@richrelevance.com> wrote:
>
> On 12/11/09 1:57 PM, "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>
>>
>> This is my big issue. dropping / creating databases for unit tests is
>> overkill. Running any DDL at all for a unit test seems wrong to me
>> too. Insert a row if you need it, MAYBE. Unit tests should work with
>> a test database that HAS the structure and database already in place.
>>
>> What happens if your unit tests get lose in production and drop a
>> database, or a table. Not good.
>>
>
> Production should not have a db with the same username/pw combination as dev
> boxes and unit tests . . .
>
> Unfortunately, unit-like (often more than a 'unit') tests can't always rely
> on a test db being already set up. If one leaves any cruft around, it might
> break later tests later on non-deterministically. Automated tests that
> insert data are absolutely required somewhere if the application inserts
> data.
>
> The best way to do this in postgres is to create a template database from
> scratch with whatever DDL is needed at the start of the run, and then create
> and drop db's as copies of that template per test or test suite.
Debateable. Last job we had 44k or so unit tests, and we gave each
dev their own db made from the main qa / unit testing db that they
could refresh at any time, and run the unit tests locally before
committing code. Actual failures like the one you mention were very
rare because of this approach. A simple ant refresh-db and they were
ready to test their code before committing it to the continuous
testing farm.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: scott.marlowe@gmail.com, scott@richrelevance.com, nik9000@gmail.com, jd@commandprompt.com, andres@anarazel.de, pgsql-performance@postgresql.org, glassresistor@gmail.com
Subject: Re: 8.4.1 ubuntu karmic slow createdb
In-Reply-To: <dcc563d10912111419y5074fab3w7f620a28a141012@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox