You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@bea.com> on 2007/03/07 03:09:19 UTC
org.apache.openjpa.persistence.test.PersistenceTestCase
Hi,
In implementing a new test case for OPENJPA-121, I decided to stop
copying-and-pasting the setUp() from other test cases, and instead
create a new PersistenceTestCase base class.
Based on our experience over the last few years, there are a bunch of
things that would be useful in such a class. I decided to just start off
with what I needed for my particular test case, though. As we move
forward, if you run across functionality that you think would make sense
in a base test case class, please consider putting it into that class.
One example might be a means to automatically delete all instances of
the types used by the test case during setUp() and tearDown().
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: org.apache.openjpa.persistence.test.PersistenceTestCase
Posted by Craig L Russell <Cr...@Sun.COM>.
On Mar 6, 2007, at 9:42 PM, Patrick Linskey wrote:
>> Which class should we use as the real base class?
>
> Hmm. SingleEMTest does have a lot more functionality, but one downside
> of it is that it obfuscates our test cases a bit, making them less
> useful as examples of JPA code usage.
Obfuscation should be eschewed.
>
>> Which project does it belong in?
>
> Sadly, in maven, there is no way (that I know of) for one module to
> extend test classes defined in a different module.
IIRC, you can declare binary dependencies for test as well as src
code. True, you cannot have sources in two different modules but
we're just looking for a binary dependency, right?
OOTH, some of the things I'd like to see in the base class for
persistence are EMF and EM, so they don't really belong too far
upstream.
> Additionally, when
> run, tests do not include the contexts of downstream modules. These
> two
> facts mean that any end-to-end test must be in openjpa-persistence-
> jdbc
> or somewhere downstream of it, and that the base class for end-to-end
> tests must be in the same module, even though it's not JDBC-specific.
>
> I can see a case for moving the tests in openjpa-persistence-jdbc to
> openjpa-jdbc-tests or something like that, but we sadly can't move the
> base class up to openjpa-persistence, even though it seems like it
> belongs there.
We can try to declare the base test case in e.g. kernel and declare a
binary dependency in persistence-jdbc.
I'll ping the maven team and see if I can get some clarity there.
Craig
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> Sent: Tuesday, March 06, 2007 7:55 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Re: org.apache.openjpa.persistence.test.PersistenceTestCase
>>
>> There's a bunch of stuff that we use in the JDO base test
>> class. I'll
>> take a look and see what might be useful for us here.
>>
>> Which class should we use as the real base class? Which project does
>> it belong in?
>>
>> Craig
>>
>> On Mar 6, 2007, at 7:50 PM, Marc Prud'hommeaux wrote:
>>
>>> Patrick-
>>>
>>> FYI, I had also put some of that sort of logic in the
>>> org.apache.openjpa.persistence.test.SingleEMTest base test case.
>>>
>>> We might want to consider merging duplicate functionality at some
>>> point.
>>>
>>>
>>>
>>> On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:
>>>
>>>> Hi,
>>>>
>>>> In implementing a new test case for OPENJPA-121, I decided to stop
>>>> copying-and-pasting the setUp() from other test cases, and instead
>>>> create a new PersistenceTestCase base class.
>>>>
>>>> Based on our experience over the last few years, there are
>> a bunch of
>>>> things that would be useful in such a class. I decided to just
>>>> start off
>>>> with what I needed for my particular test case, though. As we move
>>>> forward, if you run across functionality that you think
>> would make
>>>> sense
>>>> in a base test case class, please consider putting it into that
>>>> class.
>>>> One example might be a means to automatically delete all
>> instances of
>>>> the types used by the test case during setUp() and tearDown().
>>>>
>>>> -Patrick
>>>>
>>>> --
>>>> Patrick Linskey
>>>> BEA Systems, Inc.
>>>>
>>>>
>> _____________________________________________________________________
>>>> __
>>>> Notice: This email message, together with any attachments, may
>>>> contain
>>>> information of BEA Systems, Inc., its subsidiaries and
>>>> affiliated
>>>> entities, that may be confidential, proprietary, copyrighted
>>>> and/or
>>>> legally privileged, and is intended solely for the use of the
>>>> individual
>>>> or entity named in this message. If you are not the intended
>>>> recipient,
>>>> and have received this message in error, please
>> immediately return
>>>> this
>>>> by email and then delete it.
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: org.apache.openjpa.persistence.test.PersistenceTestCase
Posted by Marc Prud'hommeaux <mp...@apache.org>.
On Mar 6, 2007, at 9:42 PM, Patrick Linskey wrote:
>> Which class should we use as the real base class?
>
> Hmm. SingleEMTest does have a lot more functionality, but one downside
> of it is that it obfuscates our test cases a bit, making them less
> useful as examples of JPA code usage.
Agreed. That is the dilemma of using a lot of test-specific logic and
helpers: it reduces the usefulness of test cases as illustration of
how to do stuff.
>> Which project does it belong in?
>
> Sadly, in maven, there is no way (that I know of) for one module to
> extend test classes defined in a different module. Additionally, when
> run, tests do not include the contexts of downstream modules. These
> two
> facts mean that any end-to-end test must be in openjpa-persistence-
> jdbc
> or somewhere downstream of it, and that the base class for end-to-end
> tests must be in the same module, even though it's not JDBC-specific.
>
> I can see a case for moving the tests in openjpa-persistence-jdbc to
> openjpa-jdbc-tests or something like that, but we sadly can't move the
> base class up to openjpa-persistence, even though it seems like it
> belongs there.
Yeah, that is unfortunate. We could move the tests into some new
openjpa-persistence-tests/java/ and make them all abstract, and then
make concrete subclasses of them all in openjpa-persistence-jdbc/
test/, which would be the nicest way to allow us to run the same
tests against different data storage back-end types. I've considered
doing this, but since the only other back-end we currently support is
the limited-functionality XMLStore, I didn't see a case for making
the effort.
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> Sent: Tuesday, March 06, 2007 7:55 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Re: org.apache.openjpa.persistence.test.PersistenceTestCase
>>
>> There's a bunch of stuff that we use in the JDO base test
>> class. I'll
>> take a look and see what might be useful for us here.
>>
>> Which class should we use as the real base class? Which project does
>> it belong in?
>>
>> Craig
>>
>> On Mar 6, 2007, at 7:50 PM, Marc Prud'hommeaux wrote:
>>
>>> Patrick-
>>>
>>> FYI, I had also put some of that sort of logic in the
>>> org.apache.openjpa.persistence.test.SingleEMTest base test case.
>>>
>>> We might want to consider merging duplicate functionality at some
>>> point.
>>>
>>>
>>>
>>> On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:
>>>
>>>> Hi,
>>>>
>>>> In implementing a new test case for OPENJPA-121, I decided to stop
>>>> copying-and-pasting the setUp() from other test cases, and instead
>>>> create a new PersistenceTestCase base class.
>>>>
>>>> Based on our experience over the last few years, there are
>> a bunch of
>>>> things that would be useful in such a class. I decided to just
>>>> start off
>>>> with what I needed for my particular test case, though. As we move
>>>> forward, if you run across functionality that you think
>> would make
>>>> sense
>>>> in a base test case class, please consider putting it into that
>>>> class.
>>>> One example might be a means to automatically delete all
>> instances of
>>>> the types used by the test case during setUp() and tearDown().
>>>>
>>>> -Patrick
>>>>
>>>> --
>>>> Patrick Linskey
>>>> BEA Systems, Inc.
>>>>
>>>>
>> _____________________________________________________________________
>>>> __
>>>> Notice: This email message, together with any attachments, may
>>>> contain
>>>> information of BEA Systems, Inc., its subsidiaries and
>>>> affiliated
>>>> entities, that may be confidential, proprietary, copyrighted
>>>> and/or
>>>> legally privileged, and is intended solely for the use of the
>>>> individual
>>>> or entity named in this message. If you are not the intended
>>>> recipient,
>>>> and have received this message in error, please
>> immediately return
>>>> this
>>>> by email and then delete it.
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
RE: org.apache.openjpa.persistence.test.PersistenceTestCase
Posted by Patrick Linskey <pl...@bea.com>.
> Which class should we use as the real base class?
Hmm. SingleEMTest does have a lot more functionality, but one downside
of it is that it obfuscates our test cases a bit, making them less
useful as examples of JPA code usage.
> Which project does it belong in?
Sadly, in maven, there is no way (that I know of) for one module to
extend test classes defined in a different module. Additionally, when
run, tests do not include the contexts of downstream modules. These two
facts mean that any end-to-end test must be in openjpa-persistence-jdbc
or somewhere downstream of it, and that the base class for end-to-end
tests must be in the same module, even though it's not JDBC-specific.
I can see a case for moving the tests in openjpa-persistence-jdbc to
openjpa-jdbc-tests or something like that, but we sadly can't move the
base class up to openjpa-persistence, even though it seems like it
belongs there.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Tuesday, March 06, 2007 7:55 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: org.apache.openjpa.persistence.test.PersistenceTestCase
>
> There's a bunch of stuff that we use in the JDO base test
> class. I'll
> take a look and see what might be useful for us here.
>
> Which class should we use as the real base class? Which project does
> it belong in?
>
> Craig
>
> On Mar 6, 2007, at 7:50 PM, Marc Prud'hommeaux wrote:
>
> > Patrick-
> >
> > FYI, I had also put some of that sort of logic in the
> > org.apache.openjpa.persistence.test.SingleEMTest base test case.
> >
> > We might want to consider merging duplicate functionality at some
> > point.
> >
> >
> >
> > On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:
> >
> >> Hi,
> >>
> >> In implementing a new test case for OPENJPA-121, I decided to stop
> >> copying-and-pasting the setUp() from other test cases, and instead
> >> create a new PersistenceTestCase base class.
> >>
> >> Based on our experience over the last few years, there are
> a bunch of
> >> things that would be useful in such a class. I decided to just
> >> start off
> >> with what I needed for my particular test case, though. As we move
> >> forward, if you run across functionality that you think
> would make
> >> sense
> >> in a base test case class, please consider putting it into that
> >> class.
> >> One example might be a means to automatically delete all
> instances of
> >> the types used by the test case during setUp() and tearDown().
> >>
> >> -Patrick
> >>
> >> --
> >> Patrick Linskey
> >> BEA Systems, Inc.
> >>
> >>
> _____________________________________________________________________
> >> __
> >> Notice: This email message, together with any attachments, may
> >> contain
> >> information of BEA Systems, Inc., its subsidiaries and
> >> affiliated
> >> entities, that may be confidential, proprietary, copyrighted
> >> and/or
> >> legally privileged, and is intended solely for the use of the
> >> individual
> >> or entity named in this message. If you are not the intended
> >> recipient,
> >> and have received this message in error, please
> immediately return
> >> this
> >> by email and then delete it.
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: org.apache.openjpa.persistence.test.PersistenceTestCase
Posted by Craig L Russell <Cr...@Sun.COM>.
There's a bunch of stuff that we use in the JDO base test class. I'll
take a look and see what might be useful for us here.
Which class should we use as the real base class? Which project does
it belong in?
Craig
On Mar 6, 2007, at 7:50 PM, Marc Prud'hommeaux wrote:
> Patrick-
>
> FYI, I had also put some of that sort of logic in the
> org.apache.openjpa.persistence.test.SingleEMTest base test case.
>
> We might want to consider merging duplicate functionality at some
> point.
>
>
>
> On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:
>
>> Hi,
>>
>> In implementing a new test case for OPENJPA-121, I decided to stop
>> copying-and-pasting the setUp() from other test cases, and instead
>> create a new PersistenceTestCase base class.
>>
>> Based on our experience over the last few years, there are a bunch of
>> things that would be useful in such a class. I decided to just
>> start off
>> with what I needed for my particular test case, though. As we move
>> forward, if you run across functionality that you think would make
>> sense
>> in a base test case class, please consider putting it into that
>> class.
>> One example might be a means to automatically delete all instances of
>> the types used by the test case during setUp() and tearDown().
>>
>> -Patrick
>>
>> --
>> Patrick Linskey
>> BEA Systems, Inc.
>>
>> _____________________________________________________________________
>> __
>> Notice: This email message, together with any attachments, may
>> contain
>> information of BEA Systems, Inc., its subsidiaries and
>> affiliated
>> entities, that may be confidential, proprietary, copyrighted
>> and/or
>> legally privileged, and is intended solely for the use of the
>> individual
>> or entity named in this message. If you are not the intended
>> recipient,
>> and have received this message in error, please immediately return
>> this
>> by email and then delete it.
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: org.apache.openjpa.persistence.test.PersistenceTestCase
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Patrick-
FYI, I had also put some of that sort of logic in the
org.apache.openjpa.persistence.test.SingleEMTest base test case.
We might want to consider merging duplicate functionality at some point.
On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:
> Hi,
>
> In implementing a new test case for OPENJPA-121, I decided to stop
> copying-and-pasting the setUp() from other test cases, and instead
> create a new PersistenceTestCase base class.
>
> Based on our experience over the last few years, there are a bunch of
> things that would be useful in such a class. I decided to just
> start off
> with what I needed for my particular test case, though. As we move
> forward, if you run across functionality that you think would make
> sense
> in a base test case class, please consider putting it into that class.
> One example might be a means to automatically delete all instances of
> the types used by the test case during setUp() and tearDown().
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.