openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Perform automatic drop and create db schema
Date Tue, 02 Jan 2007 21:20:44 GMT

Personally, I like to put both the data cleanup and data  
initialization in the setUp() stage. It's sometimes a bit slower, but  
if there is faulty cleanup logic in a previous test's tearDown(), it  
may affect some random test down the road, and it can sometimes be  
very difficult to track down.

TCKs that come out of Sun are especially notorious for this problem :)



On Jan 2, 2007, at 4:07 PM, Craig L Russell 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.
>
> 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.
>
> JUnit facilitates this by providing a setUp and tearDown. We create  
> the test data in setUp and delete it in tearDown. Of course, the  
> tearDown might fail, leaving the data in an unpredictable state,  
> but it does work 99.9% of the time. That's why we have a common  
> tearDown that is very carefully implemented to catch exceptions,  
> retry, etc.
>
> Craig
>
> On Jan 2, 2007, at 12:52 PM, Marc Prud'hommeaux wrote:
>
>> Robert-
>>
>> I completely agree. We usually just build all the tables once and  
>> then just try to make sure all the objects are deleted at the end  
>> of the test, but you are correct that this is sometimes more  
>> cumbersome than it could be. An easy drop-then-create option would  
>> simplify this, although some databases can be notoriously slow  
>> with schema interrogation and manipulation that doing it for each  
>> test might wind up being prohibitively slow.
>>
>>
>>
>> On Jan 2, 2007, at 3:44 PM, robert burrell donkin wrote:
>>
>>> On 1/2/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
>>>> Shay-
>>>>
>>>> Unfortunately, we don't have any automatic drop-table feature,  
>>>> but I
>>>> agree it would be handy (you might want to make a JIRA report with
>>>> the suggestion).
>>>>
>>>> The only other recourse, I think, would be to just manually delete
>>>> the database files before running your tests.
>>>
>>> support for easy integration testing is one area where i think many
>>> JDO implementations could really improve
>>>
>>> it's vital to start with a known database state and clean up after
>>> each integration test. this isn't as easy as it should be when you
>>> have a complex object-relational mapper with extensive caching. a  
>>> set
>>> of side doors for integration testing would really help  
>>> productivity.
>>>
>>> - robert
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


Mime
View raw message