You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Abe White <aw...@bea.com> on 2006/10/19 19:30:52 UTC
Re: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java
Kevin --
Thanks for the test case. Unfortunately, the test will always fail
for databases that don't support auto-assigning column values. The
test should probably look for DBDictionary.supportsAutoAssign and
skip itself (early on, before any attempt to create the schema for
the classes involved), if auto-assigning isn't supported. You can
then test the test, by changing the DerbyDictionary's
supportsAutoAssign to false and making sure running it still works.
On Oct 19, 2006, at 6:38 AM, kwsutter@apache.org wrote:
> Log:
> Testcase for a problem similar to the one described in OPENJPA-13.
> Revision 453016 resolved both of these problems. We can use this
> testcase for regression purposes.
_______________________________________________________________________
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: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java
Posted by Kevin Sutter <kw...@gmail.com>.
On 10/19/06, Patrick Linskey <pl...@bea.com> wrote:
>
> Also, I noticed that you have a tearDown() in your test case.
> Historically, we've typically not written tearDown() methods, and just
> put the tear-down logic in the beginning of setUp().
That's funny, 'cause I copied one of the existing testcases to base my
testcase off of so that I would be following the normal practices... :-)
No big deal. I can be used as the guinea pig. I can handle it...
I understand the
> value of having a separate tearDown() to keep things clean, but it'd be
> good if you called tearDown() at the beginning of setUp() in case the
> database state is invalid to begin with.
>
> I'm raising this on the list because I think it'd be good for us to
> figure out what we want our setUp()/tearDown() practices to look like
> moving forward.
Agree.
So, I guess I should put this in the form of a vote:
>
> [ ] Separate setUp() and tearDown()
> [ ] Separate setUp() and tearDown(), but setUp() invokes tearDown()
> [X] Typically no tearDown(); put cleanup logic in setUp()
> [ ] Other. Please describe.
If we want to ensure a clean database state for setUp(), then providing a
separate tearDown() method doesn't make much sense since it would always be
invoked by the framework anyway. That is, it would be called twice. We
might as well just include the cleanup logic in the setUp() method. And, if
it's too cumbersome, then we could provide a utility method that could be
called from setUp().
And, since we're discussing junit features, could we or should we be
entertaining any of the junit 4 features such as the support for the
@Before, @After, @BeforeClass, and @AfterClass annotations?
Of course, we're talking about guidelines, not rules, here. There are
> obviously cases that will deviate from whatever we agree on.
>
> Thoughts?
>
> -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: Kevin Sutter [mailto:kwsutter@gmail.com]
> > Sent: Thursday, October 19, 2006 11:14 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: svn commit: r465623 - in
> > /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/jav
> a/org/apache/openjpa/persistence/generationtype: ./ >
> IdentityGenerationType.java TestGenerationType.java
> >
> > Thanks, Abe. Will take care of this shortly.
> >
> > On 10/19/06, Abe White <aw...@bea.com> wrote:
> > >
> > > Kevin --
> > >
> > > Thanks for the test case. Unfortunately, the test will always fail
> > > for databases that don't support auto-assigning column values. The
> > > test should probably look for DBDictionary.supportsAutoAssign and
> > > skip itself (early on, before any attempt to create the schema for
> > > the classes involved), if auto-assigning isn't supported. You can
> > > then test the test, by changing the DerbyDictionary's
> > > supportsAutoAssign to false and making sure running it still works.
> > >
> > > On Oct 19, 2006, at 6:38 AM, kwsutter@apache.org wrote:
> > >
> > > > Log:
> > > > Testcase for a problem similar to the one described in OPENJPA-13.
> > > > Revision 453016 resolved both of these problems. We can use this
> > > > testcase for regression purposes.
> > >
> > >
> > ______________________________________________________________
> > _________
> > > 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: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java
Posted by Abe White <aw...@bea.com>.
> [ x] Separate setUp() and tearDown()
> [ ] Separate setUp() and tearDown(), but setUp() invokes tearDown()
> [ ] Typically no tearDown(); put cleanup logic in setUp()
> [ ] Other. Please describe.
IMO, if we're diligent in writing proper tearDown methods, there's no
reason to put the tearDown logic in setUp. The only reason we got
into that habit in Kodo was that we were sloppy with our test case
cleanup.
_______________________________________________________________________
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: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java
Posted by Patrick Linskey <pl...@bea.com>.
Also, I noticed that you have a tearDown() in your test case.
Historically, we've typically not written tearDown() methods, and just
put the tear-down logic in the beginning of setUp(). I understand the
value of having a separate tearDown() to keep things clean, but it'd be
good if you called tearDown() at the beginning of setUp() in case the
database state is invalid to begin with.
I'm raising this on the list because I think it'd be good for us to
figure out what we want our setUp()/tearDown() practices to look like
moving forward.
So, I guess I should put this in the form of a vote:
[ ] Separate setUp() and tearDown()
[ ] Separate setUp() and tearDown(), but setUp() invokes tearDown()
[ ] Typically no tearDown(); put cleanup logic in setUp()
[ ] Other. Please describe.
Of course, we're talking about guidelines, not rules, here. There are
obviously cases that will deviate from whatever we agree on.
Thoughts?
-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: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, October 19, 2006 11:14 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: svn commit: r465623 - in
> /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/jav
a/org/apache/openjpa/persistence/generationtype: ./ >
IdentityGenerationType.java TestGenerationType.java
>
> Thanks, Abe. Will take care of this shortly.
>
> On 10/19/06, Abe White <aw...@bea.com> wrote:
> >
> > Kevin --
> >
> > Thanks for the test case. Unfortunately, the test will always fail
> > for databases that don't support auto-assigning column values. The
> > test should probably look for DBDictionary.supportsAutoAssign and
> > skip itself (early on, before any attempt to create the schema for
> > the classes involved), if auto-assigning isn't supported. You can
> > then test the test, by changing the DerbyDictionary's
> > supportsAutoAssign to false and making sure running it still works.
> >
> > On Oct 19, 2006, at 6:38 AM, kwsutter@apache.org wrote:
> >
> > > Log:
> > > Testcase for a problem similar to the one described in OPENJPA-13.
> > > Revision 453016 resolved both of these problems. We can use this
> > > testcase for regression purposes.
> >
> >
> ______________________________________________________________
> _________
> > 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: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java
Posted by Kevin Sutter <kw...@gmail.com>.
Thanks, Abe. Will take care of this shortly.
On 10/19/06, Abe White <aw...@bea.com> wrote:
>
> Kevin --
>
> Thanks for the test case. Unfortunately, the test will always fail
> for databases that don't support auto-assigning column values. The
> test should probably look for DBDictionary.supportsAutoAssign and
> skip itself (early on, before any attempt to create the schema for
> the classes involved), if auto-assigning isn't supported. You can
> then test the test, by changing the DerbyDictionary's
> supportsAutoAssign to false and making sure running it still works.
>
> On Oct 19, 2006, at 6:38 AM, kwsutter@apache.org wrote:
>
> > Log:
> > Testcase for a problem similar to the one described in OPENJPA-13.
> > Revision 453016 resolved both of these problems. We can use this
> > testcase for regression purposes.
>
> _______________________________________________________________________
> 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.
>