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 >
