openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] Propose additional uses for openjpa-integration
Date Wed, 20 May 2009 20:48:23 GMT
For #2, if we moved the lockmgr tests out of o-p-j, then we could use 
the derby.locks.deadlockTimeout property to speed up the other tests in 
that module by at least 5 mins.....


-Donald


Jeremy Bauer wrote:
> Donald,
> 
> Great ideas.  Comments inline.
> 
> On Tue, May 19, 2009 at 12:10 PM, Donald Woods <dwoods@apache.org> wrote:
> 
>> There are two scenarios that I'd like us to consider using the
>> openjpa-integration component for testing in trunk -
>>
>> 1) Validation - using a new integration subproject to test our optional
>> bean validation support against one or more providers.  This will allow us
>> to keep the junits in openjpa-persistence-jdbc focused on the default no
>> validator scenarios.
> 
> 
> +1 A simple mechanism to allow running with multiple validation providers
> would be very beneficial.  Not burdening the existing test bucket with
> validation is also a good idea.  While most of the tests would not do any
> real validation (since there are no validation constraints on the entities),
> they would still incur the cost of loading up the validator and making the
> validation attempt.  Additional execution time for little benefit: -1.
> 
> 2) Lock/Timeout testing - moving most of the lockmgr and lock/query timeout
>> tests out of openjpa-persistence-jdbc to a new integration subproject to
>> reduce the time required to run the main-line tests
>>
>> Both of the above subprojects would be setup to always run in the tests
>> goal, so top-level builds would still run all of the existing plus new
>> junits.
>>
>> -1 While it would be really nice to have o-p-j build faster, I think moving
> these tests into the integration subproject would make it difficult to
> differentiate what should/should not go into that subproject.  IMHO,
> execution time should not be a deciding factor when choosing whether to add
> something to the integration subproject.
> 
>> A future scenario to consider, would be moving DB specific tests (that
>> target a single DB like Oracle, DB2, ...) into integration subprojects, so
>> every junit that remains in openjpa-persistence-jdbc is always active (not
>> excluded in surefire or skipped due to the DBDictionary) and should always
>> pass on every supported DB.
>>
> 
> +1 I think this is a good idea.  It would also provide a structured means to
> add, locate, and run database specific tests.  This is fairly ad-hoc at the
> moment.
> 
> -Jeremy
> 
>>
>>
>> -Donald
>>
> 

Mime
View raw message