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 <[email protected]> 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
