Agree, but as long as everyone runs a top-level build before committing
changes, then the tests would still be run, while shortening the time
required to perform repetitive builds in the o-p-j module...
-Donald
Pinaki Poddar wrote:
Hi Donald,
If primary motivation for this proposal is to speed up the test execution
-- I support that. But I do not like the idea of splitting test corpus in
smaller buckets to achieve that goal or reflecting this goal on project
module structure.
There is a need for sure to be able to run a subset of tests while a
development is focused on a relatively isolated aspect. But I have seen it
many a times that a rather innocuous change in one part of the software
propagates in its impact to an apparently unrelated segment (and this
behavior is generic to *any* discreet system, not only to OpenJPA). That is
the downside risk if we promote test corpus to be spread/split.
DWoods 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.
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.
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.
-Donald
-----
Pinaki Poddar http://ppoddar.blogspot.com/
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
