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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
