openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: [DISCUSS] Propose additional uses for openjpa-integration
Date Tue, 19 May 2009 18:01:43 GMT
Good idea, Donald.  Thanks for taking the initiative.  More comments inline.

On Tue, May 19, 2009 at 12:10 PM, Donald Woods <> 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.

Great idea.  Separation of concerns.

> 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

Hmmm....   Not clear on how these are "integration" tests.  I can understand
that these lock tests take up some "unnecessary" time, but they are probably
still good to run with the normal test runs.  I suppose if top-level builds
are still executed before we commit, we might be okay.  It just might be
giving a false-positive on the initial testing.  Instead of lumping these in
with integration, maybe there's another subproject for locking 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.

As I was reading your above ideas, the DB testing came to mind as well.
This would be an excellent idea, especially for those DB-specific tests.

Kind of related to all of this is the current (on-going) discussion
surrounding the various ways of enhancing our classes.  We have found that
the complete bucket does not execute with sub-classing support, nor does it
run completely with the java agent setup.  I know that Rick started
experimenting with breaking down some of the tests into a common subset that
will run against all enhancement scenarios.  Sounds like maybe we could or
should extend your ideas with these enhancement scenarios.


> -Donald

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message