db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Code coverage for client.net package
Date Thu, 07 Jun 2012 00:52:11 GMT
On 6/6/2012 4:10 AM, Knut Anders Hatlen wrote:
> However, it looks like a lot of the code is handling errors, many of 
> them protocol errors (which would only happen if there's a bug in the 
> server or the client) or very unlikely errors (like 
> NetResultSetReply.parseCloseError() which is only called if the server 
> experienced an error in ResultSet.close()). It's very hard to test 
> this code, and it might even require changes on the server to force it 
> to generate errors while testing. It might be easier to start with the 
> classes that implement the java.sql interfaces in the client.am 
> package, as most of their methods could be called directly from the 
> test. I see for example that classes like LogicalPreparedStatement and 
> LogicalCallableStatement have very little coverage. 

For protocol errors usually these are only exercised with the protocol 
tests. (By adding them to protocol.tests in the derbynet  package and 
running derbynet.ProtocolTest.  That said, that process can be somewhat 
painful and  I don't think they are high value test cases as really 
although the client needs to handle them, they should not happen in 
normal operation.

I  think for a summer project it is good to focus on method vs block 
coverage and agree it is a higher priority and easier  to get the basic 
sql interface implementation methods covered on the client.

Kathey


Mime
View raw message