openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phill Moran" <pjmo...@rogers.com>
Subject RE: Unit testing
Date Mon, 09 Apr 2007 17:02:10 GMT
+1
It should be part of the commit acceptance process. Otherwise OpenJPA will loose
out to other ORM tools that will be perceived as less buggy. 
What is used for coverage monitoring, clover? We should also use checkstyle to
give some insight into the code as well

Phill

-----Original Message-----
From: Patrick Linskey [mailto:plinskey@bea.com] 
Sent: April 9, 2007 12:51 PM
To: open-jpa-dev@incubator.apache.org
Subject: Unit testing

Hi,

I'm a bit concerned about the lack of unit tests being put into OpenJPA as new
features are added. I understand that often, creating unit tests are
anticlimactic compared to implementing the feature itself, but at least basic
happy-path testing of new features is pretty essential if we want to avoid these
types of problems. Code inspection is good but, Abe's good eyes aside, not as
reliable as having a unit test that will start failing when a feature is broken.

I try to write my test cases first, in a somewhat-modified TDD approach.
I do this because a) I need some sort of harness to demonstrate the failure in
order to isolate and resolve it, and b) I know that personally, I'm much more
likely to write a test while the problem is still interesting than after it's
resolved. In other words, I never (well, rarely) have a command-line harness
that I throw together to demonstrate a problem. I try to always use a test case
instead. This strategy means that the only test-related overhead is the effort
involved to figure out how to programmatically test for failure.

Also, I understand that some things are hard to test. Testing SQL or JDBC
interactions is often percieved to be one of these things. In the Kodo codebase,
we ended up creating various means to get around this; the SQLListenerTestCase
is one such example. It turns out that by extending SQLListenerTestCase, it
becomes trivial to check how much SQL was written and what the SQL looks like.

Does anyone else have any thoughts about how to ensure that we develop test
cases as needed?

-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: Abe White
> Sent: Monday, April 09, 2007 8:12 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Resolved: (OPENJPA-208) NoResultException and 
> NonUniqueResultException are not thrown when expected
> 
> > Went ahead and restored the previous behavior where the QueryImpl 
> > itself checks for non-uniqueness and throws the expected exception.
> 
> That breaks the single result optimization that was added for
> OPENJPA-168 when getSingleResult() is called.  There was a reason we  
> moved the validation to the kernel.  The previous code was correct.   
> You need to use the "hard" way of creating new exception types.
> 
> 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.
> 

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.


Mime
View raw message