openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: Collaborative Testing
Date Thu, 03 Jul 2008 17:20:40 GMT
I'm looking at this from a help to resolve JIRA issues standpoint. There are
other benefits too that I might have left out.

On Thu, Jul 3, 2008 at 11:57 AM, Craig L Russell <>

> Hi Pinaki,
> On Jul 3, 2008, at 8:50 AM, Pinaki Poddar wrote:
>> Hi,
>>  A growing body of developers are using OpenJPA and reporting their use
>> case scenarios, error report via the Nabble posts. This process generates
>> wealth of unstructured information.
>>  Here is a proposal to add some structure to it:
>> 1. We publish and distribute the common utilities of OpenJPA's JUnit based
>> test harness.
> We already do this, don't we?

Not exactly. We publish them in that the source is available in the source
zip files, and in SVN. They aren't available as compiled binaries as far as
I know.

Test classes are not included in the maven repositories (either local or
remote) by default. We could achieve this by using a classifier and
explicitly creating a test jar - there are drawbacks to this approach

So I guess it depends on what you mean by publish. I think it'd be really
nice if maven users could just add


to pom.xml and then write their testcase. Non maven users would have to
download the openjpa-persistence-tests jar file from the maven repository
manually and add it to their classpath. Either way might help others to
contribute testcases.

>> 2. We request/mandate that submission of a JIRA report accompany a test
>> case
>> written in accordance to OpenJPA-JUnit based tests.
> Mandate might be a bit strong, but given documentation (see below) we can
> certainly encourage people to provide regression tests.
>> This way, we can build a diverse test corpus gradually.
>> To get this done, we need to
>> 1. Document our JUnit Test harness related classes (such as
>> SingleEMFTestCase etc.). They already are well-documented -- perhaps a
>> small
>> write-up on 'How to write OpenJPA test' manual.
> This seems to be the biggest hurdle. Figuring out which test class to
> inherit and which package to put the test case into, and whether there is an
> existing schema/mapping/test class that fits the requirement.
> Perhaps encouraging users to name the test something like
> to refer to OPENJPA-659 might be useful  as well.

Avoiding duplicate testcases is tricky. I don't think we can expect everyone
who reports a bug to weed through our test structure and find the right
place to put them. I'd be happy with a simple testcase or the object model
that can be used to reproduce the issue. The committer can figure out where
the testcase belongs when she/he commits the change.

To help with this problem we might want to consider using one of the code
coverage tools that integrate "nicely" with Maven. I believe there are at
least a few that we could try.

>> 2. Extend our build so that these tests classes are distributed with their
>> source code in a separate bundle.
> This sounds like a lot of work, but might be easier than getting
> contributors to check out and build the source tree from svn.

I don't think it will be too bad actually. Admittedly I was only thinking of
including the "base" test classes (SingleEMFTestCase, SingleEMTestCase etc.)
in a separate module.

>> 3. Promote the users' to contribute their test cases
> +1

+1 as well.

> Craig
>> --
>> View this message in context:
>> Sent from the OpenJPA Developers mailing list archive at
> Craig L Russell
> Architect, Sun Java Enterprise System
> 408 276-5638
> P.S. A good JDO? O, Gasp!
> -mike

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