Re: svn commit: r465623 - in /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype: ./ IdentityGenerationType.java TestGenerationType.java

[Craig L Russell]

Hi,






[ +1] Separate setUp() and tearDown()

Craig

On Oct 19, 2006, at 12:39 PM, Patrick Linskey wrote:

I like to have both setUp and tearDown in my test cases. In another project, we created a "mother of all test cases" and defined a setUp and tearDown there that did some routine stuff that many test cases needed, such as removing persistent instances that would cause subsequent test case failures. But we should at least have setUp and tearDown defined in each test case, so:

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

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.


by email and then delete it.

value of having a separate tearDown() to keep things clean, but it'd be ______________________________________________________________________ _ 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

-----Original Message-----
From: Kevin Sutter [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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.

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!

smime.p7s
Description: S/MIME cryptographic signature