Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of robertburrelldonkin@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Szo2jQefpQYpZMew+VMGAi7gTYgQRHQNBamuL31QLqrCwAOe1wp3u6Ot/m2laZ+w4lqlAg/BCpMS66GjRybNsYsAKqPAxv0K/It0hFR2pUAbZygawXSgxvpX8FY96U43xS4w5lqY9477TYVLji+7XO8SVfT+dR08dPIrSAlN418=
Message-ID: <f470f68e0701021338x4ea13ff6q1c73bdaafdcf0919@mail.gmail.com>
Date: Tue, 2 Jan 2007 21:38:52 +0000
From: "robert burrell donkin" <robertburrelldonkin@gmail.com>
To: open-jpa-dev@incubator.apache.org
Subject: Re: Perform automatic drop and create db schema
In-Reply-To: <1545FDED-9B00-4912-A398-8FF7CA5FC029@SUN.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <8130220.post@talk.nabble.com>
	 <6B556C6A-48CC-4BEA-9514-3ABD1F655C93@apache.org>
	 <f470f68e0701021244l5e9c6584w615294eb357b2a76@mail.gmail.com>
	 <F2AFA4C6-6690-426B-8583-BA91A4846E3E@apache.org>
	 <1545FDED-9B00-4912-A398-8FF7CA5FC029@SUN.com>

On 1/2/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> For What It's Worth:
>
> +1 on the drop-tables feature for OpenJPA. But I would caution
> against using it on each test.
>
> Sadly, my experience is that drop-create-tables is 99.9% of the time
> taken in a typical test.
>
> The JDO TCK runs hundreds of tests and we drop-create tables only on
> demand. The drop-create step takes several minutes compared to a few
> seconds to actually run the tests.

yeh - dropping then recreating isn't very efficient but is effective

i've found that it's hard to educate developers unfamiliar with
automated testing. creating good integration tests is important but
takes a long while. too often neglected due to time pressure. i
suspect that tool developers could do more to help.

for example, IMHO containers should ship with integrated code coverage
tools. there are good enough open source ones but since they are not
bundled with containers they are not used as widely as they should be
in commercial development work.

> After several years of doing this kind of work, I've concluded that
> the best practical strategy (we tried beating up the database vendors
> to make drop-create as fast as insert/delete rows, to no avail) is to
> write your tests such that at the beginning of the test, you create
> your test data and at the end of the test, you delete the test data,
> leaving the database in an empty state.

+1

but this is where a side door would be of most use. sophisticated
object relational layers generally make it relatively slow and
unnatural to just delete everything in a table. which is as it should
be. it'd just be cool to able if the tool developers also created
testing only side doors.

i have an idea that this is all reasonably easily doable but isn't
well known or packaged up into tools which are easy to learn.

it would be very cool to be able to start a recording tool in setup to
intercept and record every create, update, delete in the data access
layer then in tearDown just ask the data access layer to undo
everything that was done.

it would also be very cool to have a complete dump and replace
facility for black-box-in-container functional testing. in setup, just
push a load of data as xml. the data access layer deletes data from
all the tables specified and inserts the given data.

easy, dynamic flushing of all object caches would also be useful.

(sadly, i'm really interested in meta-data ATM, both email and source
auditing so there's not much chance of hacking together something
which demonstrates what i mean any time soon...)

- robert